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INTRODUCTION 


The  SRS  Data  Processing  Task  Force  was  reestablished  by 
the  Director  on  August  21,  1981,  with  the  following 
members: 


Ron  Brown 

Bob  Donaldson 

Pete  Surdock 

Doug  Egan 

Jim  Sveinson 

Bill  Ikard 

Mike  Muszkiewicz 


Chairman 

RS/VS 

Community  Services 

Statistics 

Data  Processing 

Economic  Assistance 

Developmental  Disabilities 


The  goal  of  this  task  force  is  to  "Develop  a  long  range 
(3  year)  data  processing  plan  for  the  department." 
Companion  to  this  goal,  two  other  goals  are  proposed  for 
adoption  by  the  department. 

•    SRS  Department  Goal — Provide   effective   services 
delivery  to  those  Monana  citizens  served. 
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*    SRS  Data  Processing  Goal--Develop  data  processing 
systems  to  facilitate  delivery  of  services. 

The  work  of  this  task  force  is  not  completed.  There  is 
a  need  to  further  develop  a  training  program,  producing 
a  handbook  containing  systems  development  policies  and 
procedures,  and  complete  the  list  of  data  elements  to 
be  standardized.  Also,  individual  divisional  DP  plans 
need  to  be  reviewed  and  recommendations  concerning  them 
submitted  to  the  SRS  Policy  Group  for  consideration. 

Policy  development  is  an  integral  part  of  the 
long-range  DP  plan,  therefore,  existing  DP  policies, 
including  Federal,  State  and  SRS  rules  and  regulations 
were  reviewed  and  are  included  in  the  appendix. 
Recommended  SRS  policies  are  included  as  a  part  of  this 
plan  in  Section  400. 
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200       OVERVIEW 


The  following  reflect  the  philosophical  basis  that  this 
committee  used  in  developing  this  plan.  Like  most 
philosophical  structures,  these  principles  contain 
redundancy  and  inconsistency.  In  employing  them  to 
specific  situations  or  decisions,  a  balancing  approach 
should  be  used. 

1.  The  Department's  Approach  to  Data  Processing  is 
Pragmatic. 

Data  Processing's  function  is  to  increase  the 
effectiveness  or  efficiency  of  the  organization. 
For  a  given  task,  automation  will  be  chosen  only 
if  it  is  the  better  solution.  Within  the  class  of 
DP  solutions  we  will  resist  dogma  and  the  "gee 
whiz"  glamour  that  often  afflict  DP  and  focus  on 
the  best  solution  for  an  application. 

2.  The  Department  Will  Use  the  Latest  Proven  DP 
Technology. 

When  the  job  can  be  done  better  by  adopting  new 
technology  we  will  acquire  that  new  technology. 
We  wish  to  have  the  most  productive  hardware  and 
software.   However,  as  the  very  newest  products 
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are  often  not  fully  developed,  we  will  prefer 
products  that  have  proven  themselves  in  the 
marketplace  and  represent  mature  technical 
advances.  Conversely,  we  wish  to  discontinue  use 
of  obsolescent  technology. 

3.  The  Department  Takes  a  Global  View  of  Systems  and 
Regards  DP  as  but  One  Component  of  a  Successful 
and  Efficient  Management  System. 

Within  this  view,  a  system  is  all  things  which  come 
together  to  produce  a  given  result.  In  order  for 
a  global  system  to  function  well,  all  components 
must  perform  properly.  Successful  (i.e. 
productive)  introduction  of  DP  into  this  global 
system  requires  that  components  which  interact 
with  the  DP  component  receive  appropriate 
attention,   including   allocation  of  resources. 

4.  Data  Processing  can  be  Successfully  Employed  to 
Automate  Only  Basically  Well  Managed  Manual 
Systems, 

If  we  automate  an  awkward,  cumbersome  manual 
system,  we  obtain  an  awkward,  cumbersome  DP 
system.  Such  an  effort  may  exacerbate  an  already 
bad  system.  Inadequate  management  or  administra- 
tive practices  must  be  remedied  before,  or 
concurrent  with  automation. 
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5.  The  Department  Should  Employ  In-House  Development 
Whenever  Possible. 

Out-of-house  costs  are  at  least  double  in-house 
development  costs.  In  addition,  valuable 
knowledge  and  working  relationships,  which  are 
needed  for  ongoing  operations  are  lost  when  the 
outside  relationship  is  ended.  Out-of-house 
services  can  serve  as  temporary  supplements  to 
in-house  resources. 

6.  End  Users  are  an  Integral  Part  of  Any  DP  Applica- 
tion or  Development. 

DP  is  only  supportive  of  the  users'  operations. 
Users  determine  the  amount,  nature  and  quality  of 
DP  support  needed.  Beyond  this  authority  rela- 
tionship, users  must  be  active  participants  in  the 
development  and  ongoing  management  of  DP  systems. 
In  order  to  enhance  the  benefits  of  DP  to  them- 
selves, users  may  need  to  perform  functions 
traditionally  performed  by  DP  specialists. 

7.  The  Department's  Priorities  Should  Assure  Equity 
to  All  Users. 
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In  the  past,  DP  resources  have  often  been 
allocated  arbitrarily  to  the  needs  of  a  few  users. 
There  are  many  legitimate  demands  on  limited  DP 
resources.  These  needs  may  involve  legal  require- 
ments, dollar  savings,  management  information  or 
other  needs.  There  must  be  a  method  of  establish- 
ing priorities  which  does  not  have  the  effect  of 
excluding  any  users  or  any  legitimate  need. 

8.  People  are  the  Most  Important  Component  of  a 
Successful  DP  Application. 

The  successful  development  or  operation  of  a  DP 
application  requires  substantial  inputs  of  human 
talents  and  skills.  These  inputs  come  from 
managers,  DP  professionals,  line  workers  and 
others.  DP  planning  must  explicitly  consider  and 
provide  for  these  human  contributions.  Through 
training,  user  manuals,  and  recruitment,  we  must 
assure  that  our  staff  has  the  needed  skills, 
knowledge,  attitudes,  and  philosophy  to  develop 
meaningful  inputs . 

9.  DP  Development  is  an  Ongoing  Process. 

Most  DP  applications  will  require  debugging  and 
fine  tuning  after  initial  implementation.   Failure 
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to  allocate  resources  to  these  efforts  will  sub- 
stantially reduce  the  efficiency  of  a  DP  applica- 
tion and  may  eventually  result  in  its  failure.  In 
addition,  information  needs  are  in  a  constant 
state  of  change.  This  requires  regular  and  timely 
review  and  updating  of  DP  applications. 

10.  The  Computer  is  Not  Magic. 

In  olden  days  people  believed  in  spirits  (good  and 
bad)  that  employed  magic  to  affect  people's  lives. 
In  modern  organizations  the  belief  in  magic 
persists.  The  modern  possesor  of  magical 
abilities  is  the  computer  rather  than  the  spirits 
of  old.  Then,  as  now,  the  belief  in  magic  is 
rooted  in  ignorance.  The  successful  application  of 
DP  technology  requires  knowledge,  good  management, 
hard  work,  and  full  cooperation  between  all  who 
are  involved  in  the  automation  process.  A  computer 
may  be  described  as  a  very  fast  and  efficient 
moron. 

11.  The  Programs  of  this  Department  are  Dynamic;  DP 
Technology  Must  be  Equally  Dynamic. 

The  rate  of  change  within  our  programs  is 
increasing.   More  change  is  introduced  by  our 
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efforts  to  improve  our  management  and  administra- 
tive practices.  DP  Technology  has  become  an 
indispensable  part  of  our  organization.  As  such 
it  has  the  potential  to  enhance  or  retard  organi- 
zational change  and  improvement.  We  will  prefer 
developments  which  are  quick  to  develop  and  quick 
to  modify.  System  designs  should  anticipate 
change  and  evolution. 

12.   Planners  of  DP  Systems  Should  Consider  Murphy's 
Three  Laws . 

I.  Nothing  is  as  easy  as  it  looks. 

II.  Everything  will  take  longer  and  will  cost  more 
than  you  think  it  will. 

III.  If  anything  can  go  wrong,  it  will. 
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300  GOALS 

301  SRS  GOAL — Effective  Delivery  of  Service  to  the  Citizens 
of  Montana. 

This  is  the  perceived  goal  of  the  departmnt,  the  SRS 
Data  Processing  Goal  being  one  of  the  many  sub-goals. 
The  SRS  Data  Processing  Goal  is  the  only  sub-goal 
addressed  in  this  report  since  it  is  the  object  of  the 
study  by  the  DP  Task  Force. 

302  SRS  DATA  PROCESSING  GOALS-- 

"  Development  of  Automated  Systems  to  Facilitate  the 
Efficient  Delivery  of  SRS  Services  to  Montana 
Citizens. 

**  Provide  Management  Information  Necessary  to  Assist 
in  the  Effective  Management  of  SRS  Programs. 
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400  OBJECTIVES  AND  RECOMMENDATIONS 

401  OBJECTIVE- -Establish  Policies  and  Procedures  for 
Preparing  and  Processing  Requests  for  Data  Processing 
Systems  and  Services. 

RECOMMENDATIONS-- 

1.  Establish  a  Data  Processing  Steering  Committee 
composed  of  members  from  each  Division,  chaired  by 
a  Division  Administrator,  and  charged  with  the 
responsibilities  and  authority  to: 

a.  Continue  the  work  of  the  DP  Task  Force  by 
maintaining  a  current  SRS  Long  Range  Data 
Processing  Plan. 

b.  Review,  approve,  disapprove,  or  make  recom- 
mendations to  the  SRS  Policy  Group  concerning 
requests  for  data  processing  services, 
hardware,  and  software  for  applicability, 
appropriateness,  and  need  based  on  the  SRS  DP 
Plan  and  established  policies. 

e.  Review  information  system  problems/recommen- 
dations and  make  recommendations  for 
resolution  to  the  Policy  Group. 
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d.  Establish  priorities  for  system  development 
or  modification  requests  or  make  recommenda- 
tions to  the  Policy  Group  as  the  situation 
dictates. 

That  the  SRS  Policy  Group  (composed  of  the 
Director,  Deputy  Directors  and  Division  Adminis- 
trators) have  the  responsibility  to: 

a.  Approve,  disapprove,  or  modify  all  SRS  DP 
policies. 

b.  Review,  approve,  disapprove,  or  modify 
recommendations  from  the  DP  Steering 
Committee  for  development  or  acquisition  of 
new  DP  Systems,  hardware,  and  software*. 
Only  those  systems  and  hardware  or  software 
items  requiring  a  significant  investment  in 
dollars  or  time,  or  over  which  a  controversy 
has  developed  between  the  requestor  and  the 
Steering  Committee,  should  be  referred  to  the 
Policy  Group. 

*  Software  is  defined  as  operating  systems 
and  utilities  necessary  to  efficiently  and 
effectively  operate  the  computer  (hardware). 
It  does  not  apply  to  computer  programs  that 
are  a  part  of  a  DP  System. 
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c.  That  priorities  for  development  or  modifica- 
tion to  a  system  be  set  by  the  Policy  Group 
when  requested  by  the  DP  Steering  Committee 
or  a  requestor  who  is  dissatisfied  with  the 
Steering  Committee's  decision. 

That  once  a  DP  system,  or  modification  to  an 
existing  system  has  been  approved,  the  hardware 
and  software  necessary  to  implement  the  system 
shall  require  no  additional  approval  action  within 
SRS.  However,  if  major  changes  to  the  hardware  or 
software  requirements  are  occassioned  by  modifica- 
tions to  the  system  during  its  development, 
approval  of  the  hardware/software  changes  by  the 
Steering  Committee  and  Policy  Group,  as  appro- 
priate, shall  be  required. 


That  a  handbook  for  Data  Processing  Users  be 
developed  by  the  DP  Steering  Committee  by 
January  1,  1982.  This  handbook  should  contain 
specific  criteria,  policies,  and  procedures  for 
developing  and  submitting  a  request  for  DP  Systems 
and  services.  Also,  the  responsibilities  of  the 
requestor  regarding  system  development,  implemen- 
tation and  operation  processes  should  be  set 
forth. 
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5.  That  the  Data  Processing  Bureau  shall  be  responsi- 
ble, with  the  concurrence  and  assistance  of  the 
appropriate  program  manager,  to  negotiate  and 
supervise  all  DP  systems  contracts  (development  or 
maintenance),  regardless  of  the  source  of  funding. 
The  Data  Processing  Bureau  shall  assist  the 
requestor  in  obtaining  the  outside  contract 
services  necessary  to  assure  timely  development  of 
systems  which  exceed  the  capability  of  the  SRS  DP 
staff. 

6.  That  the  Data  Processing  Bureau  shall  be  responsi- 
ble to  prepare,  with  the  assistance  of  the 
affected  program  manager(s),  and  submit  advanced 
Data  Processing  (ADP)  Plans  to  the  Federal 
Government,  when  required. 

7.  That  the  Data  Processing  Bureau  be  responsible  for 
coordination  and  obtaining  necessary  approvals 
from  the  State  DP  Coordinator  and  the  Department 
of  Administration  and  other  departments  as 
necessary. 

402       OBJECTIVE — Establish   and   Maintain   an   SRS   Data 
Processing  Plan  Based  on  Division  Data  Processing  Plans 


400-4 


RECOMMENDATIONS  — 

1.  That  each  division  establish  a  one  year  minimum  DP 
Plan  to  identify  DP  systems  necessary  to  satisfy 
their  informations  needs.  To  accomplish  this, 
each  division  would  review  its  activities  and 
identify  functions  which  can  be  automated 
resulting  in  saving  of  staff  time  or  money  while 
maintaining,  as  a  minimum,  the  quality  of  service 
delivery  currently  experienced  by  manual  opera- 
tions. This  plan  is  to  be  furnished  the  DP 
Steering  Committee  by  February  1,  1982. 

2.  That  each  division  update  their  plan  annually  by 
June  1  each  year  and  furnish  updates  to  the  DP 
Steering  Committee  (this  update  would  also  extend 
the  plan  one  fiscal  year). 

3.  That  the  Data  Processing  Bureau  furnish  the  DP 
Steering  Committee  an  initial  report,  by 
January  15,  1982  and  by  June  30  each  year 
thereafter,  identifying  significant  accomplish- 
ments in  the  area  of  system  development,  modifica- 
tions, etc,  and  the  status  of  each  project  under 
development.  Also,  this  report  should,  based  on 
requests  currently  being  worked  on  and  those 
pending,  project  availability  of  development  staff 
time  over  the  next  year. 
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4.  That  the  DP  Steering  Committee  review  updated 
division  plans  and  the  DP  Bureau  annual  reports 
and  provide  and  updated  SRS  DP  Plan  to  the  Policy 
Group  by  August  15  each  year. 

403  OBJECTIVE — To  Assure  Data  Processing  Systems  are 
Responsive  to  the  User's  Information  Needs  at  All 
Organizational  Levels 

RECOMMENDATIONS-- 

1.  That  the  following  performance  standards  be  a  part 
of  the  system  specifications  for  all  new  systems. 
For  this  purpose,  a  "system"  comprises  the  entire 
process  from  creation  of  data  to  disposition  of 
outputs  which  includes  manual  as  well  as  automated 
processes  and  involves  both  program  and  DP  Bureau 
activities. 

a.  Simple   reports   involving   only   selection, 
listing,  and  summarization  shall  be  produced 
within  48  hours  of  the  request. 

b.  Detail  data  about  individual  cases  or  trans- 
actions shall  be  available  to  the  line  worker 
within  minutes.  This  may  be  either  a  manual 
or  automated  process. 
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c.  Complex  reports  that  require  elaborate 
selection,  computation  or  data  transformation 
must  be  available  within  5  work  days  of 
request. 

d.  Requests  that  involve  minor  file  modifica- 
tion, such  as  adding  a  data  element  or 
changing  codes  of  an  existing  data  element 
must  be  programmed  and  tested  within  30  days. 
Gathering  and  entering  the  changed  data  may 
take  longer. 

e.  Major  system  changes  that  involve  large 
additions,  changes  to  file  structure  or  basic 
processing  procedures  should  be  accomplished 
within  90  days  of  receipt  of  the  request  by 
the  DP  staff. 

f.  For  needs  that  require  data  that  is  not 
recorded  in  a  DP  system,  there  shall  be  a 
capability  of  gathering  and  reporting  the 
data  within  30  days  using  alternative 
methods,  i.e.,  statistical  sampling. 

g.  The  above  standards  shall  be  met  for  80%  of 
the  requests  and  assumes  that  all  required 
actions  have  been  taken  by  the  requestor 
prior  to  submitting  the  request. 
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2.  That  the  following  criteria  be  used  when  determin- 
ing whether  a  system  should  be  on-line,  batch,  or 
a  combination  on-line/batch. 

a.  System  development  time; 

b.  System  development  and  operational   costs; 

c.  System  inputs  and  volume; 

d.  System  outputs  and  reporting  requirements; 

e.  Data  collection  method; 


f.   Update  requirements; 


g.    Timely  access  to  information; 


h.   Privacy  and  security  controls/requirements; 


i.    On-line  response  time; 


j.   Turnaround  time; 


k.    System  volatility; 
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1.    Life  expectancy; 

m.   Backup/recovery  time; 

n.   Availability  and  maintenance  of  equipment; 

o.   Efficient  use  of  staff  and  staff  time  trade- 
offs. 

3.  That  DP  systems  be  written  so  as  to  utilize  only 
those  software  languages  which  the  Department 
supports  and  for  which  the  Department  can  provide 
technical  backup.  The  use  of  all  other  software 
languages  should  be  for  "one-time"  applications 
and  justified  by  exceptional  conditions  according 
to  the  criteria  established  by  the  DP  Steering 
Committee. 

4.  That  insofar  as  is  practical,  all  new  systems  be 
as  user  friendly  as  possible.  See  Appendix  "A" 
for  further  discussion  of  "user  friendly". 

404  OBJECTIVE--Standardizing  Some  Data  Elements  to  Facili- 
tate Interface  Between  Systems,  Information  Retrieval, 
and  System  Design. 
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RECOMMENDATIONS-- 

1.  That  all  new  systems  use  standardized  data 
elements  insofar  as  is  practical. 

2.  That  a  DP  Steering  Sub-Committee  be  appointed  to 
develop  a  list  of  standard  data  elements  for 
approval  of  the  full  committee.  This  list  should 
be  completed  by  December  1,  1981  and  included  in 
the  user's  handbook. 

405      0BJECTIVE--TO  avoid  System  Duplication. 

RECOMMEND AT I ONS - - 

1.  That  the  inventory  of  SRS  Data  Processing  Systems 
listed  in  Section  600  be  updated  monthly. 

2.  That  as  new  systems  are  requested,  they  be 
compared  to  the  current  inventory  to  avoid 
duplication. 

3.  That  the  Director  of  SRS  request  that  a  statewide 
inventory  of  data  processing  systems  existing  in 
Montana  State  Government  agencies  be  developed  by 
the  State  DP  Management  Group  by  June  30,  1982, 
and  be  made  available  for  use  by  all  State 
agencies. 
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406  OBJECTIVE — To  Use  the  Computer  to  Maximize  the 
Efficient  and  Effective  Utilization  of  Staff  Time  and 
to  Reduce  Costs. 

RECOMMENDATION— 

That  it  be  the  policy  of  this  Department  that  Adminis- 
trators, Bureau  Chiefs,  and  other  management  staff 
shall  creatively  explore  and  implement  appropriate  use 
of  more  efficient  and  less  costly  automated  computer 
systems  to  replace  manual  systems. 

407  OBJECTIVE--T0  Assure  All  DP  Systems  Are  Current  and 
Relevant. 

RECOMMENDATION— 

Establish  as  agency  policy  that  all  automated  computer 
systems  be  reviewed  by  program  and  data  processing 
staff  on  a  periodic  basis  (minimally  once  a  year)  to 
assure  they  are  relevant,  current,  and  responsive  to 
current  program  need. 

This  requirement  should  be  divided  into  two  parts.  1) 
DP  should  review  for  the  latest  changes  in  technology 
and  2)  Programs  should  review  for  requirement  changes. 
This  does  not  infer  that  changes  would  not  be  made  as 
necessary  on  an  ongoing  basis,  only  that  such  a  review 
is  required  and  should  be  formalized  by  policy. 
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408  OBJECTIVE — To  Assure  That  Each  Data  Processing  System 
Is  Adequately  Documented. 

RECOMMENDATIONS  — 

1.  That  System  documentation  be  developed  for  each 
computer  system  in  accordance  with  standards 
established  by  the  data  processing  steering 
committee.  (See  Appendix  "A"  for  more  on  documen- 
tation. ) 

2.  That  all  documentation  be  reviewed  by  the  Data 
Processing  Bureau  to  assure  the  standards  are  met. 

3.  That  one  complete  copy  of  each  system  documenta- 
tion shall  be  filed  in  the  Data  Processing  Bureau, 
regardless  of  who  developed  the  system. 

4.  All  changes  as  a  result  of  maintenance  or  modifi- 
cations to  existing  systems  shall  be  documented 
and  included  with  the  original  system  documenta- 
tion. 

409  OBJECTIVE — To  Provide  Data  Processing  Training  To  SRS 
Staff  At  All  Organizational  Levels. 
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RECOMMENDATIONS-- 

1.  That  the  data  processing  training  program  for 
regular  and  ongoing  training  be  developed  by  Staff 
Development  and  reviewed  for  content  and  approval 
by  the  Data  Processing  Steering  Committee  prior  to 
implementation  by  February  15,  1982. 

2.  That  the  Data  Processing  Steering  Committee 
conduct  periodic  reviews  of  the  training  package 
content  for  relevancy  and  appropriateness.  (See 
Appendix  "A"  for  more  on  training. ) 

^^°       OBJECTIVE— To  provide  Adequate  Security  For  Information 
Contained  In  Computer  Systems. 

RECONMENDAT I ONS - - 

1.  That  the  degree  of  security  be  commensurate  with 
the  sensitivity  of  the  data  in  each  system  and  be 
in  conformity  to  State  or  Federal  law,  Department 
Rules,  and  the  respective  Division  rules  on 
confidentiality. 

2.  All  systems  shall  limit  access  to  prevent 
unauthorized  data  manipulation.  (See  Appendix  "A" 
for  more  on  system  security. ) 
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500       DEFINITION  OF  TERMS 

Hardware  -  is  defined  as  physical  equipment,  as  opposed 
to  the  computer  program  or  method  of  use,  for  example, 
mechanical,  magnetic,  electrical,  or  electronic 
devices . 

Software  -  is  a  set  of  programs,  procedures,  and 
possibly  associated  documentation  concerned  with  the 
operation  of  a  data  processing  system.  For  example, 
compilers,  library  routines,  manuals,  circuit  diagrams. 
For  the  purpose  of  this  discussion,  software  is  limited 
to  operating  systems,  utilities,  etc.,  not  specific  DP 
system  programs. 

Maintenance  -  That  which  is  necessary  to  keep  the 
system  operating  in  its  present  form,  including 
debugging,  restoration  of  files,  correction  of  programs 
causing  the  system  to  abend,  production  recovery,  etc. 

Ad  Hoc  Reports  -  Those  "one-time"  reports  necessary  to 
satisfy  a  specific  (primarily  program)  need  for  which 
documentation  is  of  little  importance  and  retention  of 
the  program(s)  creating  the  report  is  of  a  short  time 
period.  Also,  these  reports  do  not  require  any  changes 
or  modifications  to  existing  systems,  programs  or 
files. 
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Minor  Changes/Modifications  to  Existing  DP  Systems 
Those  changes  which  require  less  than  100  DP  person 
hours  to  complete.  They  can  be  caused  by  requirements 
being  changed,  to  provide  for  an  unforeseen 
requirement,  to  add  or  reduce  the  systems'  dimensions, 
etc.  The  key  here  is  the  length  of  time  it  takes  to 
make  the  change. 

Major  Changes/Modifications  to  Existing  DP  Systems 
Those  changes  requiring  more  than  100  DP  person  hours 
to  make.  These  may  be  caused  by  the  same  forces  as 
minor  changes/modifications.  Oftentimes,  major  changes 
significantly  change  the  scope  and  size  of  the  system 
being  changed.  The  terms  "changes"  and  "modifications" 
are  interchangeable  (synonymous)  and  include  terms  such 
as  "enhancements",  "rewrites",  etc. 

Development  of  New  Systems  -  The  design,  development, 
installation,  and  operation  of  a  DP  system  which  does 
not  now  exist  within  the  department.  This  may  also 
include  modifying  systems  developed  by  other  depart- 
ments or  purchased  from  a  commercial  vendor. 

Data  Entry  -  The  physical  act  of  converting  data  into  a 
format  acceptable  to  a  computer  system.  This  may 
either  be  "batch",  which  is  accomplished  in  house  by 
the  DP  Bureau  Data  Entry  Section  (key  to  diskette),  or 

500-2 


by  contract  with  the  Department  of  Administration  or 
other  data  entry  service,  or  "on-line"  via  CRT. 
"On-line"  data  entry  shall  be  the  responsibility  of  the 
user,  not  the  DP  Bureau. 
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600        INVENTORY  OF  CURRENT  DP  SYSTEMS 
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700        AUTOMATED  INFORMATION  NEEDS 

The  Automated  Information  Needs  outlined  below  are 
those  for  which  sufficient  information  is  available  to 
specifically  address  at  this  time. 

Additional  information  needs  will  be  available  in 
greater  detail  when  the  Division  Data  Processing  Plans 
are  received,  reviewed,  and  prioritized. 

Most  of  the  information  needs  listed  are  of  a  short- 
term  nature,  but  will  occupy  the  DP  Bureau  system 
development  resources  at  least  until  June  30,  1982. 

1.  Maintain  those  automated  systems  presently  in 
operation.  This  includes  production  recovery  and 
those  changes  needed  to  continue  operation  in  the 
system's  current  configuration. 

2.  Complete  those  requests  for  systems  modification, 
new  systems,  etc.,  for  which  commitments  have  been 
made.  Requests  received  after  approval  of  this 
plan  shall  be  reviewed  by  the  DP  Steering 
Committee  for  assignment  of  a  priority,  unless  the 
number  of  requests  do  not  exceed  the  DP  Bureau's 
projected  resources.  The  requests  presently  in 
the  DP  Bureau  are  primarily  for  modifications  to 
the  R-300/E&E  and  MIM  systems  and  completion  of 
the  Title  XX  system. 
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A  complete  review  of  these  systems  and  their 
related  requests  is  essential  to  assure  that  only 
that  work  absolutely  necessary  to  accomplish  the 
system's  purposes  is  performed.  The  R-300/E&E 
system  is  currently  undergoing  such  a  review  and  a 
Project  Director  for  the  Title  XX  system  is  now  on 
board. 

Remove  those  DP  systems  currently  operating  on  the 
System  32  by  June  30,  1981,  and  dispose  of  the 
System  32  by  July  31,  1982. 

The  System  32  utilizes  RPG  II  as  its  program 
language  which  cannot  be  supported  by  the  DP 
staff.  A  recommendation  that  we  utilize  only 
languages  supportable  by  the  DP  staff  is  contained 
in  Section  405. 

The  System  32  is  physically  located  in  the  Word 
Processing  Center  and  approximately  .5  WP  operator 
FTE  is  required  to  operate  the  systems  located 
thereon.  This  detracts  from  the  WP  capabilities 
and  does  not  represent  effective  use  of  WP  staff. 

In  addition  to  making  all  SRS  DP  systems  support- 
able by  the  DP  Bureau  staff,  this  action  will 
reduce  software  rental  and  maintenance  costs  of 
the  System  32  by  $3,600  per  year. 
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Systems  presently  on  the  System  32  and  their 
disposition  are  outlined  below. 

•*     ACCOUNTS  RECEIVABLE  SYSTEM  -- 

This  system  is  designed  to  track  amounts  owed 
the  department  by  nursing  homes,  AFDC  and 
food  stamp  recipients,  foster  care/day  care 
providers,  etc.  When  rewritten,  some  modifi- 
cations need  to  be  made  to  make  it  a  more 
usable  tool  for  managing  our  financial 
resources. 

°     EMPLOYEE  LEAVE  ACCOUNT  SYSTEM  -- 

The  system  needs  only  to  be  rewritten  in  a 
supportable  language.  No  changes  are  to  be 
made.  Also,  this  system  will  be  necessary 
only  until  the  Statewide  Leave  Accounting/ 
Payroll/Personnel  System  is  installed. 

"     DAILY  CHECK  LOG  -- 

This  system  records  all  checks  received  by 
the  Fiscal  Bureau  and  produces  daily  and 
monthly  listings  for  audit  trail  purposes. 
This  would  be  a  straight  conversion  with  no 
known  changes . 
700-3 


WORD  PROCESSING  PRODUCTION  DATA  -- 

The  system  calculates  and  reports  the  number 
of  lines  and  pages,  by  user,  produced  by  the 
WP  Section.  These  data  are  used  for  allocat- 
ing this  operation's  costs  as  indirect  costs. 

SRS  TELEPHONE  ALPHABETICAL  LISTING  -- 

This  system  is  driven  by  the  payroll  extract 
used  to  update  the  Leave  Accounting  System 
and  by  manual  inputs  of  telephone  number 
changes.  It  produces  an  alphabetical  listing 
of  all  SRS  employees,  location,  and  telephone 
number.  This,  too,  would  be  a  straight- 
forward conversion  effort. 

DEVELOPMENTAL  DISABILITIES  INVOICING 
SYSTEM  -- 

This  system  will  no  longer  be  required  after 
implementation  of  the  Title  XX  system. 
Therefore,  no  conversion  effort  is  required. 
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°     CHILDRENS'  TRUST  ACCOUNTS  — 

This  system  has  never  achieved  its  intended 
goal,  therefore,  a  manual  backup  system  has 
also  been  maintained.  This  system  is  no 
longer  used;  however,  a  requirement  for 
automating  the  manual  system  still  exists. 
This  automation  will  be  in  the  form  of  a  "new 
system  development  request"  and  will  be 
included  in  the  Centralized  Services  Division 
Data  Processing  Plan. 

4.  Rewrite  the  MIM  System — This  project  has  not  had 
its  goals  and  objectives  defined.  Because  this 
project  could  consume  a  significant  amount  of  DP 
staff  hours  over  a  prolonged  period  of  time,  its 
goals  and  objectives  are  essential  if  a  meaningful 
SRS  DP  Plan  is  to  be  formulated.  Specific  goals 
and  objectives  should  be  developed  for  this 
project  by  February  1,  1982. 

5.  Low  Income  Energy  Assistance  Program  System — This 
program,  inherited  from  DCA  July  1,  1981,  requires 
the  development  of  an  automated  system  to  deliver, 
track,  and  pay  for  this  service.  Like  the  MIMS, 
specific  goals  and  objectives  need  to  be  developed 
so  that  the  amount  of  resources  required  may  be 
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estimated.  This  will  then  allow  a  decision  as  to 
whether  in-  or  out-of-house  development  is  appro- 
priate and  if  developed  in-house,  its  effect  on 
other  information  needs. 

6.   Montana   Medicaid   Information   System   (MIMS) 
Feasibility  Study — 

The  MMIS  is  currently  operated  by  the  Hancock/ 
Dikewood  Corporation,  the  contracted  fiscal  agent. 
Past  experience  with  the  contractor  indicates  that 
a  feasibility  study  to  bring  the  MMIS  in-house  may 
be  appropriate.  Because  of  size  and  complexity  of 
this  system,  a  significant  amount  of  planning  and 
lead  time  would  be  required  if  it  were  to  be 
brought  in-house.  Also,  for  the  above-stated 
reasons,  in-house  development  with  our  present 
development  staff  would  be  impossible.  However, 
the  effect  on  other  systems  must  also  be 
considered  in  terms  of  demands  on  DP  staff  time. 
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APPENDIX  "A" 

ADDITIONAL  INFORMATION  RELATING  TO 
OBJECTIVES  AND  RECOMMENDATIONS 

401  OBJECTIVE — Establish  Policies  and  Procedures  for 
Preparing  and  Processing  Requests  for  DP  Systems  and 
Services . 

The  need  to  have  a  standing  committee  to  address  DP 
issues  and  requests  for  services  cannot  be 
overemphasized.  This  committee  would  screen  all 
requests  for  new  systems  and  system  modifications  and 
develop  policies  and  procedures  relating  to  Data 
Processing.  Only  policy  and  major  new  systems  and 
modifications  or  those  over  which  there  is  controversy 
would  be  referred  to  the  Policy  Group.  This  would 
significantly  reduce  the  number  of  items  requiring  the 
time  of  the  Policy  Group. 

This  Steering  Committee  would  meet  at  least  monthly  or 
more  often  if  necessary  to  review  requests  and  develop 
DP  policy.  Having  each  division  represented  will  also 
serve  to  enhance  intra-departmental  communications 
concerning  DP  matters  which  is  in  need  of  considerable 
improvement. 
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The  task  of  deciding  which  project  to  do   first, 
particularly  when  the  number  of  requests  exceeds  the 
number  of  DP  Bureau  development  staff  hours,  will  be 
the  responsibility  of  the  Steering  Committee  or  Policy 
Group  rather  than  the  DP  Bureau  Chief. 

Requests  would  be  submitted  to  the  DP  Bureau  for  an 
estimate  of  the  number  of  hours  necessary  to  complete 
the  project.  The  DP  Bureau  will  then  forward  them  to 
the  Steering  Committee  Chairperson  for  presentation  to 
the  Steering  Committee.  The  Steering  Committee  would 
then  disapprove  and  return  the  request  to  the 
originator,  or  approve  the  request  and  assign  a 
priority.  These  procedures  will  be  further  defined  and 
included  in  the  "User  Handbook" . 

402  OBJECTIVE --Establish  and  Maintain  an  SRS  Data 
Processing  Plan  Based  on  Division  Data  Processing 
Plans. 

In  order  to  determine  specific  management  information 
needs,  two  basic  questions  must  be  answered.: 

°    What  are  or  should  we  now  be  doing? 

"    What  information  do   we   need   to   do  the  job 
effectively  and  efficiently? 
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These  questions  must  be  answered  by  program  managers, 
at  least  in  general  terms.   Data  processing  staff  are 
available  to  assist  in  answering  these  questions,  but 
only  in  an  advisory  capacity  relative  to  the  how  of 
determining  needs  (Requirements  Definitions). 

403  OBJECTIVE--T0  Assure  Data  Processing  Systems  are 
Responsive  to  the  Users  Information  Needs  at  all 
Organizational  Levels. 

System  Flexibility  and  Responsiveness  to  User  Needs. 

Data  Processing  systems  must  be  responsive  to  user 
information  needs  at  the  various  levels  within  the 
organization.  These  information  needs  deal  with  deci- 
sion making,  planning,  program  monitoring  and  manage- 
ment, etc.,  therefore,  the  degree  of  detail  and 
frequency  necessary  for  each  function  and  organization- 
al level  will  vary  widely.  The  line  worker  may  need 
detailed  lists  of  individual  recipients.  Upper  manage- 
ment levels  need  summarization.  There  are  many  other 
qualitative  differences  in  the  kinds  of  information 
needed  by  each  level  of  management.  DP  systems 
development  must  explicitly  acknowledge  these  levels 
and  provide  capabilities  for  providing  the  needed 
information  to  each  level. 
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The  practice  of  management  is  dynamic.  The  problems 
that  we  face  today  are  not  those  of  last  year  or  even 
last  month.  They  are  largely  unpredictable.  Often  the 
problems  and  decisions  faced  are  the  result  of  outside 
elements  such  as  changing  laws  or  emerging  social 
issues.  Yet,  with  this  lack  of  certainty  about  the 
future,  current  DP  system  design  methodology  requires 
rigid  specification  of  output  requirements  (i.e., 
future  information  needs).  This  problem  cannot  be 
overcome  with  more  comprehensive  specifications  of 
output  requirements  which  would  result  in  the  gathering 
and  output  of  huge  amounts  of  data  which  "might"  be 
needed.  Beyond  the  costs  of  this  approach,  the  very 
bulk  of  the  outputs  would  frustrate  the  manager's 
search  for  information  to  manage  the  program. 

To  meet  this  objective,  the  department  needs  to  assure 
futuristic  planning,  anticipation  of  need,  and  prompt 
response  to  staffing,  equipment,  and  training  needs  as 
they  pertain  to  data  processing.  In  addition,  this 
objective  necessitates  the  establishment  of  an  ongoing 
interfacing/communicating  mechanism  that  assures  open, 
frank,  and  informed  exchange  of  information.  This  can 
only  be  achieved  through  the  establishment  of  a 
committee  composed  of  members  representing  each  SRS 
Division  and  charged  with  the  responsibility  and 
authority  to  plan,  establish  and  modify  the  SRS  Data 
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Processing  Plan;  and  to  review  DP  system  needs  of  all 
kinds  for  applicability  and  appropriateness  in  view  of 
the  SRS  Data  Processing  Plan. 

Batch  vs  On-Line  Systems 

On-line  is  defined  as  1)  pertaining  to  equipment  or 
devices  under  control  of  the  central  processsing  unit, 
2)  pertaining  to  a  user's  ability  to  interact  with  a 
computer. 

An  on-line  system  in  teleprocessing,  is  a  system  in 
which  the  input  data  enters  the  computer  directly  from 
the  point  of  origin  or  in  which  output  data  is  trans- 
mitted directly  to  where  it  is  used. 

Teleprocessing  is  the  processing  of  data  that  is 
received  from  or  sent  to  remote  locations  by  way  of 
telecommunication  lines. 

Batch  processing  is  defined  as  1)  pertaining  to  the 
technique  of  executing  a  set  of  computer  programs  such 
that  each  is  completed  before  the  next  program  of  the 
set  is  started,  2)  pertaining  to  the  sequential  input 
of  computer  programs  or  data. 
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Typically,  on-line  systems  require  more  justification 
than  a  batch  system  due  to  the  increased  costs  asso- 
ciated with  development  and  on-going  operational  costs. 

When  determining  the  merits  on  an  on-line  system  vs  a 
batch  system  consideration  should  be  given  to  the 
following  areas: 


System  development  time 

System  inputs  and  volume 

System  outputs   and  reporting  requirements 

Data  collection  method 

Update  requirements 

Timely  access  to  information 

Privacy  and  security  controls/requirements 

System   development   and   operational   costs 

On-line  response  time 

Turnaround  time 

System  volatility 

Life  expectancy 

Backup/recovery  time 

Availability  &  maintenance  of  equipment 


There  are  systems  which  are  a  combination  on-line/ 
batch.  MIMS  is  an  example  -  it  is  basically  a  batch 
system  with  on-line  inquiry  capabilities. 
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Systems  To  Be  User  Friendly 

Decision  making  systems  should  be  designed  to  be  user 
friendly. 

Systems  need  to  be  built  with  the  recognition  that  this 
agency  requires  employees  to  be  familiar  with  several 
hundred  pages  of  regulations.  We  do  have  a  high 
turnover  and  we  also  are  forced  to  change  regulations 
frequently.  User  friendly  systems  require  that  the 
policy  be  established,  tested,  and  evaluated  in  terms 
of  the  needs  of  our  clients  and  line  workers. 

A  user  friendly  system  takes  into  account  that  every 
worker  does  not  have  access  to  comprehensive  training 
in  all  aspects  of  a  program  and  also  that  some  workers 
do  not  have  quick  access  to  a  supervisor. 

User  friendly  systems  take  a  very  complicated  decision 
and  break  it  down  into  manageable  pieces. 

On-line  updates  whether  to  the  host  computer  or  done  on 
a  smart  terminal  should  have  built  in  edit  capabilities 
which  are  designed  to  encourage  the  operator  to  give 
the  correct  answer.  Edirs  of  alpha  vs  numerical  data, 
lengths  of  fielis,  etc.  should  be  developed  by  Data 
Processing  and  edits  of  policy  should  be  developed  by 
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program  policy  staff.  For  example,  if  the  operator 
punches  "yes"  to  a  certain  question,  the  computer  in  a 
user  friendly  system  will  automatically  make  a  decision 
as  to  whether  or  not  the  next  question  needs  an  answer. 
The  system  should  be  set  up  to  omit  the  questions  which 
apply  to  some  cases  but  not  to  the  case  in  question. 

User  friendly  systems  require  much  more  communication 
between  the  user  and  the  system  than  has  been  the  case 
in  conventionally  designed  systems. 

They  are  not  as  valuable  if  you  are  using  the  system  to 
only  store  data  but  if  you  desire  the  system  to  aid  in 
the  decision  making  process  they  strongly  encourage  the 
correct  decisions  and  discourage  errors. 

User  friendly  systems  take  advantage  of  the  fact  that 
computer  hardware  is  rapidly  going  down  in  price 
whereas  the  luxury  of  having  a  line  worker  spend 
several  hours  researching  a  problem  is  rapidly 
increasing  in  cost  both  from  a  labor  standpoint  and  a 
potentially  wrong  decision  causing  an  expensive  error. 

Computers  are  thought  of  as  "big  brothers"  and  very 
impersonal  by  many  users  but  by  developing  friendly 
systems  we  can  combat  this  notion  and  give  workers  more 
time  to  work  with  clients  and  less  time  filing  our 
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paperwork.  User  friendly  systems  do  not  need  to  be 
big,  they  can  accomplish  a  task  which  must  be  very 
accountable  such  as  getting  money  to  a  client  with  a 
high  degree  of  accountability  much  faster  than  the  old 
type  system  and  assure  greater  accuracy  by  requiring 
the  worker  to  give  the  proper  answer  to  each  necessary 
question  while  eliminating  the  unnecessary  question. 

Frequently,  in  the  past,  systems  required  the  worker  to 
fill  in  the  blanks  but  accepted  whatever  was  entered. 
This  caused  much  "garbage  in/garbage  out".  The  user 
friendly  systems  require  a  lot  more  thought  and  logic 
in  the  development  process  but  if  built  correctly 
eliminate  much  of  the  bad  data  problem  that  has  haunted 
systems  in  the  past. 

User  friendly  systems  use  psychology  rather  than 
bureaucracy  by  being  polite,  courteous,  and  helpful. 
Just  as  it  has  been  proven  that  workers  respond  better 
to  friendly  co-workers  and  helpful  supervisors  rather 
than  overly  official  type  personnel,  the  same  holds 
true  with  systems. 

In  the  past,  systems  often  demanded,  "Give  me  the 
correct  answer",  and  often  got  a  guess  for  an  answer 
whereas  in  the  user  friendly  concept  you  must  give  the 
line  worker  the  tools  to  make  the  correct  decision  and 
give  the  process  much  more  thought. 
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The  discussion  of  this  subject  has  been  primarily  aimed 
at  field  workers,  it  equally  applies  to  all  levels  in 
the  organization. 

While  "user  friendly"  may  be  a  valid  objective  of  a  DP 
system,  forces  such  as  standardization  and  efficiency 
may  work  against  achieving  optimum  friendliness  in  a 
system.  A  true  "user  friendly"  system  is  generally  an 
"on-line"  system. 

User  friendly  systems  cannot  be  designed  unless  policy 
staff  are  able  and  willing  to  define  policy  into  very 
simple  determinations,  since  policy  must  be  decided  in 
the  field  based  on  these  small  pieces  of  information 
rather  than  the  more  global  concept  which  historically 
was  made  available  to  the  line  worker.  The  user 
friendly  system  requires  some  reeducation  of  some 
policy  makers . 

User  friendly  systems  normally  require  user  input 
rather  than  operator  input.  This  means  that  you  are 
often  using  a  higher  paid  employee  to  enter  data  but  by 
having  the  entry  be  an  interactive  process  you  are 
increasing  the  knowledge  skills  of  your  worker.  This 
enables  the  worker  to  improve  their  interview  skills  as 
if  the  worker  knows  the  computer  will  require  a  special 
answer  when  the  client  answers  a  question  the  worker 
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will  then  learn  only  to  ask  clients  the  needed 
pertinent  questions. 

This  process  is  especially  valuable  when  you  have  new 
policy,  worker  turnover,  or  a  situation  which  occurs 
very  seldom  in  a  particular  county.  It  also  helps 
insure  that  clients  do  not  have  to  make  repeated  visits 
to  the  office  to  add  new  pieces  of  information. 

404  OBJECTIVE — Standardizing  Some  Data  Elements  To 
Facilitate  Interface  Between  Systems,  Information 
Retrieval  and  Systems  Design. 

Data  elements  are  individual  items  of  information  that 
comprise  a  computer  records  such  as  ID  number,  rate  of 
pay  amount,  etc.  Currently,  each  DP  application  can 
uniquely  establish  the  content,  meaning,  and  physical 
characteristics  of  these  data  elements.  For  example, 
birth  date  may  be  recorded  as  032853  on  one  file, 
630328  on  another,  and  MAR281963  on  another  file.  This 
generates  several  inefficiencies  in  the  DP  process. 

The  benefits  of  standardization  would  be: 

1.  increased  efficiency  in  programming,  system  design 
and  output.  This  would  occur  because  less 
research  would  be  needed  and  because  tables  and 
program  segments  could  be  borrowed  from  other 
jobs. 
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2.  a  standard  ID  number  would  allow  interface  and 
exchange  of  data  with  other  systems.  Standardiza- 
tion of  other  data  elements  would  allow  general 
purpose  programs  to  serve  several  systems.  For 
example,  standard  addresses  could  be  fed  to  a 
program  which  generates  address  labels. 

A  survey  of  current  and  proposed  systems  would  have  to 
be  conducted  to  determine  those  data  elements  used  by 
more  than  one  system.  The  following  are  some  common 
elements:  address,  name,  county,  dates,  dollar  amounts, 
vendor  ID  numbers,  disability  identifier,  worker 
number,  race,  sex,  property  ID,  welfare  category,  etc. 

To  be  standardized  would  be  data  element  length  (i.e., 
6  characters  for  dates,   9  for  zipcode  etc.),  type 
(alpha,  numeric,  packed),  and  content  (i.e.,  for  county 
1  =  Beaverhead  and  56  =  Yellowstone). 

Data   elements   unique   to   a   system  would   not  be 

standardized,  for  example  foster  care  custody.  The 

standards  policy  would  provide  other  exemptions  and 
procedures  for  deviation. 

Standards  would  be  set  to  conform  with  federal  or  state 
laws  and  rules,  established  practices  and  efficiency  of 
data  entry  and  programming. 
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A  sub-task  force,  chaired  by  Doug  Egan  has  been 
appointed  to  develop  a  list  of  common  data  elements  and 
their  attributes . 

405       OBJECTIVE — Avoid  Systems  Duplication 

The  department  should  make  effective  use  of  existing 
systems  and  programs  to  avoid  duplication. 

The  multiple  use  of  existing  systems  should  not, 
however,  create  a  difficult  or  unmanagable  system  to 
operate,  maintain  or  understand  and  use  by  a  user. 

The  department  should  review  the  use  of  data  base  and 
shared  data  files.  Repetition  or  duplication  of  data 
capture  and  on-line  storage  of  common  data  should  be 
avoided. 

The  merits  of  data  base  (if  any)  vs  the  maintenance  of 
several  files  containing  some  of  the  same  data  elements 
(provided  the  data  elements  are  standardized)  would  be 
some  of  the  criteria  used  in  evaluating  the  type  of 
system  to  be  developed.  Some  duplication  may  not  be 
bad  if  it  promotes  simplification  and  efficiency  or 
reduces  costs. 


A-13 


406  OBJECTIVE — To  Use  the  Computer  to  Maximize  the 
Efficient  and  Effective  Utilization  of  Staff  Time  and 
to  Reduce  Costs 

A  primary  purpose/objective  in  any  management  system, 
but  specifically  in  DP  Systems  is  the  efficient  use  of 
staff.  Today's  demands  on  SRS  staff  and  the  mandate  at 
both  Federal  and  State  levels  as  well  as  good 
management  principals  requires  that  the  skills  and 
talents  of  staff  be  used  in  the  most  effective  and 
efficient  manner  possible.  This  mandates  that  cheaper 
and  faster  ways  be  identified  and  utilized  for  task 
accomplishment. 

This  later  concept  also  encourages  the  maximum 
utilization  of  the  computer  for  a  variety  of  purposes. 

The  SRS  Data  Processing  System  needs  to  facilitate  and 
encourage  the  development  of  DP  systems  which  remove 
from  staff,  tasks  that  are  more  easily  and  accurately 
done  by  machine.  The  emphasis  is  not  necessarily  on 
replacement  of  staff.  The  focus  is  on  freeing  staff 
time  to  perform  tasks  frequently  given  only  glance 
attention  because  of  time  consuming  manual  tasks. 

The  DP  systems  need  to  enable  cost  savings  either 
through  more  effective  use  of  staff  time  or  better 
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management  information  (i.e.,  fraud  detection,  etc.) 
or  combining  several  tasks  performed  by  several  staff 
allowing  for  redistribution  of  task  and  reduction  in 
staff  position  allocations.  DP  systems  also  have  the 
task  of  enabling  elimination  of  duplication  of 
functions,  programs,  storage  of  data,  reports,  etc., 
thus  saving  costs  of  operations. 

To  meet  such  objectives,  agency  policy  needs  to 
assertively  encourage  and  assist  administrators, 
chiefs,  and  other  management  staff  to  creatively 
explore  appropriate  use  of  the  computer  to  replace 
manual  systems  with  more  efficient  and  less  costly 
automated  systems. 

408       OBJECTIVE — To  Assure  That  Each  Data  Processing  System 
is  Adequately  Documented 

Each  computer  system  must  be  sufficiently  documented  to 
permit  its  maintenance  or  modification  by  the  data 
processing  staff  without  reference  to  those  individuals 
involved  in  its  development. 

Documentation  should  be  commensurate  with  the  systems' 
size  and  complexity.  As  an  example,  the  documentation 
for  a  large,  complex  system,  such  as  MIMS,  R-300,  etc., 
must  be  much  more  detailed  than  those  for  a  system  of 
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significantly  less  complexity;  however,  the  documenta- 
tion for  either  system  must  meet  the  criteria  outlined 
in  1,  above. 

One-time  reports  require  no  documentation.  Once  the 
report  is  run,  there  is  no  need  for  further  use  of  the 
program(s)  creating  the  report. 

Systems,  regardless  of  who  develops  them  (DP,  user, 
etc.),  containing  significant  information  (historical, 
financial,  client  tracking,  etc.)  and/or  which  are  run 
on  a  scheduled  basis,  must  be  documented.  There  needs 
to  be  a  cut-off  point  in  regards  to  the  amount  of 
person  hours  expended  in  developing  the  program(s) 
(system)  where  documentation  requirements  are  or  are 
not  required. 

Documentation  should  be  developed  in  accordance  with 
established  standards  and  reviewed  by  someone  to  assure 
the  standards  are  met.  The  standards  must  be  flexible 
enough  to  adapt  to  different  situations. 

One  complete  copy  of  each  system  documentation  should 
be  filed  in  the  DP  Bureau,  regardless  of  who  developed 
the  system. 
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All  changes  (maintenance  or  modifications)  to  existing 
systems  must  be  documented  and  included  with  the 
original  system  documentation. 

In  addition  to  the  documentation  stored  in  the  DP 
Bureau  and  by  the  user,  if  applicable,  all  documenta- 
tion should  be  stored  off-site.  One  of  the  ways  to 
effect  off-site  storage  is  by  entering  it  on  ATMS 
(Advanced  Text  Management  System)  where  it  is  stored  in 
Central  Data  Processing  (CDP).  An  advantage  to  ATMS  is 
its  amendability  to  updating  the  documentation. 
Another  possibility  is  to  store  it  as  a  part  of  the 
program  in  the  computer  or  store  it  via  word  processing 
dikettes,  both  on  and  off  site. 

System  Documentation  -  A  Discussion 

Systems  Documentation  sometimes  referred  to  as  Master 
Documentation  or  Central  Documentation  refers  to  the 
creation,  maintenance,  and  distribution  of  all 
documentation  that  uses  a  common  set  of  documents.  It 
contains  information  on  how  the  system  was  developed 
and  how  it  works  including  input  -  output  forms  design, 
system  flowcharts,  program  specifications/definitions, 
user  and  data  processing  operating  instructions,  etc. 
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The  following  is  an  extract  from  a  data  processing 
handfcook  which  illustrates  the  master  documentation 
concept.  It  should  be  noted  however  that  actual 
content  and  quality  of  any  documentation  is  dependent 
upon  managements  committment  and  established 
documentation  standards,  which  varies  greatly  from 
installation  to  installation. 

Master  Documentation 

The  master  documentation  file  contains  all  system 
development  and  operations  documentation.  The  primary 
characteristic  of  this  file  is  the  absence  of  any 
document  duplication. 

The  master  documentation  index  provides  two 
distribution  lists.  The  development  distribution  list 
describes  the  various  management  systems  and 
programming  manual  contents  that  are  required  during 
the  system  development  process.  The  operations 
distribution  list  describes  the  contents  of  the  user 
and  data  processing  operations  manuals.  Within  each  of 
these  manuals,  provisions  are  made  for  further 
segmentation  (clerical,  keypunch,  computer,  etc.) 
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Documentation  Contents 

The  master  documentation  file  consists  of  seven  major 
sections--introduction,  management  summary,  user 
description,  database  description,  computer 
description,  automated  documentation,  and  data 
processing  instructions — plus  appendixes. 

Introduction 

This  section  describes  the  purpose  of  the  documentation 
manual,  how  the  manual  is  organized,  and  the  contents 
of  the  manual.  If  the  master  documentation  is  standard 
for  all  systems,  this  section  can  be  written  one  time 
and  then  copied  for  each  new  system  documentation 
manual . 

Management  Summary 

This  section  is  one  of  the  most  important  pieces  of  the 
system  documentation--yet  it  rarely  exists.  It  should 
be  written  so  that  all  managers  (top,  user,  and  data 
processing)  can  understand  it.  The  scope  of  the 
management  summary  should  include  the  system  interface 
wtih  other  manual  and  automated  systems.  Desired 
system  changes  and  extensions  are  usually  known  by  the 
time  a  system  is  installed,  and  they  should  be  recorded 
in  this  section. 
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User  Description 

This   section   should   be   written   in   a   deductive 
manner— that   is,   it   should   start  with   a  general 
description  of  the  system  and  then  proceed  to  segment 
it  into  subsystems  and  the  actual  system  elements 
(input  forms,  output  reports,  and  a  description  of  each 
data  field  described  by  the  inputs  and  outputs). 
Flowcharts  may  be  of  many  different  types.    Some 
systems  are  concerned  with  the  flow  of  paper  (orders, 
invoices,  etc.).   Others  use  existing  inputs  and  are 
concerned  with  only  the  computer  processing  that  is  to 
be  accomplished.  Materials  and  paper  (data)  flowcharts 
can   often   be   combined,   especially   in   shipping, 
receiving,  production  reporting,  and  the  like. 

When  preparing  the  user  documentation,  state  the 
purpose  and  objectives  of  each  segment  of  the  system, 
follow  it  with  flowcharts  or  other  pictorial  figures, 
and  then  narrate  the  figure,  referring  to  the  system 
inputs  and  outputs  as  needed.  The  resultant 
documentation  must  describe  the  system  in  adequate 
detail  to  the  system  user,  the  database  designer,  and 
the  computer  designer.  Information  related  to  inputs 
and  outputs  should  also  be  documented  with  the  data 
processing  and  user  groups  in  mind. 
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The  inputs  portion  of  this  section  should  include: 

An  index  listing  each  input  form  and  its  number. 

The  input  abstract  sheet  that  describes  general 

information   about   the   form   (source,   volumes, 

purposes,  etc. ) . 

The  input  form  (and/or  an  example). 

Form  preparation  instructions  that  describe  each 

entry  on  the  form  to  the  user  responsible  for  its 

preparations  (unless  they  are  entered  in  the  data 

element  dictionary,  making  their  inclusion  here 

unnecessary) . 

Formats  for  entering  the  input  forms . 

The  outputs  portion  of  this  section  should  include: 

An  index  listing  each  output  report  and  its 

number. 

The  output  report  abstract  sheet  that  describes 

general  information  about  the  report  (sequence, 

distribution,  purpose,  etc.). 

The    output    report    layout    (and/or    an 

example ) --though  often  it  is  more  desirable  to 

include  a  set  of  computer-produced  reports  under 

separate  cover. 
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If  the  data  element  dictionary  exists  in  manual  form, 
it  should  be  included  in  the  user  description  section. 
There  should  be  a  name/page  index  at  the  front  of  the 
dictionary  to  assist  the  reader  in  quickly  locating 
data  elements.  Once  there  is  a  data  element 
dictionary,  creating  the  input/output/data  element 
cross-reference  matrix  is  easy. 

Data  Base  Description 

As  data  bases  become  more  and  more  complex  in  terms  of 
structure,  access  methods,  file  administration 
(maintenance,  retention,  etc.),  and  data  volume,  the 
database  section  of  the  manual  becomes  increasingly 
important.  The  general  part  of  this  section  should 
include: 

The      database      structure      (sequential, 

indexed-sequential,   integrated,   inverted,   etc.) 

and  considerations  in  determining  the  structure. 

Access   methods   (sequential,   direct,   indirect, 

random,  etc. ) . 

Key  and  record  buffer  considerations  (i.e.,  room 

for  expansion) . 

File  control  characters  (record  status,  processing 

status,  etc. ) . 
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File  conversion  considerations  (from  the  current 

system) . 

Processing  guidelines  for  the  computer  design 

step. 

File  administration   (maintenance,   storage,   and 

retention  controls). 

An  index  to  the  files  should  be  in  file  number  sequence 
with  the  file  name  and  type  included.  The  file  type 
will  be  either  input,  master,  work,  history,  or  report. 

The  file  abstract  sheet  describes  all  pertinent 
information  about  the  file  (volumes,  processing 
frequencies,  record  lengths,  etc.).  The  file 
definition  sheet  describes  each  data  element  in  the 
record,  keys,  buffer  areas,  and  so  forth.  The  file 
layout  sheet  is  a  graphical  picture  of  the  records. 
(This  sheet  is  not  necessary,  but  many  data  processing 
organizations  are  reluctant  to  part  with  it.  ) 
Regardless  of  whether  or  not  there  is  a  data  element 
dictionary,  the  file/data  element  cross-reference 
matrix  is  easy  to  create  if  standard  data  names  are 
used  throughout  all  files. 
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Computer  Description 

This  section  of  the  manual  is  orientated  toward  the 
computer  solution.  It  describes  how  the  computer 
applies  the  input  data  to  the  database  and  extracts 
data  from  the  database  to  prepare  the  output  reports. 

The  general  portion  of  this  section  describes  certain 
programming  rules  and  computer  design  considerations. 
Specifically,  these  rules  include: 

Machine  type  and  size  (memory  and  peripherals). 
Software,  including  its  special  uses  and  subsets. 
Program  buffer  size  (e.g.,  some  computer  designs 
specify  that  every  program  must  reserve  5  percent 
of  core  memory  for  later  expansion). 
Other  standards  that  apply  to  this  system  but  are 
not  part  of  the  documentation  standards  manual. 

The  computer  narrative  describes  (in  terms  of  the 
job-linkage  flowchart)  how  data  pass  through  the  system 
and  where  the  major  processing  takes  place.  The 
program/file  cross-reference  matrix  should  connect 
reads,  writes,  and  read-and-writes. 

All  program  specifications  should  be  written  in  terms 
of  the  module  dependency  chart,  the  individual  module 
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(subroutine)  specifications,  and  the  module  detailed 
flowchart  (if  it  exists).  If  all  module  dependency 
charts  are  drawn  prior  to  writing  the  program 
specifications,  common  (general)  and  standard  modules 
can  be  identified  and  defined  separately,  which  will 
reduce  the  overall  implementation  effort.  The  standard 
(preceded)  modules  can  be  entered  in  the  computer 
library. 

The  computer  library  portion  of  this  section  should 
contain  an  index  noting  the  name  of  each  entry  and  the 
name  under  which  it  is  catalogued.  The  library  should 
include  these  entries: 

Standard  programming  modules 

File  descriptions 

Record  descriptions 

Test  data  (unit,  system,  and  combined) 

Other  (catalogued  procedures,  utility  job  cards, 

etc.  ) 

Automated  Documentation 

This  section  of  the  manual  must  be  included  under 
separate  cover  since  it  consists  of  such  material  as 
magnetic  files,  program  listings,  automated  flowcharts, 
test  data  printouts,  and  data  element  dictionary 
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listings.  All  these  data  should  be  retained  in  the 
computer  library  in  magnetic  form. 

Data  Processing  Instructions 

This  is  the  section  of  the  manual  that  tells  data 
processing  personnel  how  to  operate  the  system.  If  the 
user  organization  has  data  control  stations,  their 
instructions  will  also  be  included  here.  This  section 
must  be  combined  with  parts  of  the  user  and  database 
descriptions  in  order  to  provide  a  full  set  of  data 
processing  operating  instructions. 

The  general  portion  describes  in  narrative  form  how  the 
system  is  to  operate  in  general,  and  discusses  how  to 
use  the  documentation  in  this  section.  The  data 
flowchart  describes  the  flow  of  data  from  one  work 
station  to  the  next  upon  entry  into  the  data  processing 
organization.  (The  flow  ends  when  the  reports  are  sent 
to  the  user. )  The  data  processing  schedule  describes 
when  the  data  are  to  be  received,  references  the 
pertinent  data-handling  procedures,  describes  when  the 
processing  is  to  be  completed  and  the  data  returned  to 
the  user  organization,  and  tells  whom  to  contact  in  the 
user  organization  in  case  of  trouble. 
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The  data  conversion,  computer,  and  unit  record 
instructions  are  usually  self-contained  and  are  copied 
directly  into  their  respective  operating  manuals.  The 
input  collection  and  preparation  describes  batching 
procedures,  balancing,  error  checking,  and  so  forth. 
The  error  correction  instructions  pertain  to  the 
computer-produced  error  reports.  These  reports  may  be 
segmented  by  user-committed  errors  and  data 
processing--committed  errors. 

Report  preparation  and  distribution  are 
self-explanatory.  Data  storage  and  retention  include 
input  forms,  magnetic  files,  and  reports. 

Appendixes 

The  appendixes  contain  a  glossary  of  system 
terms — which  may  be  user  terms  defined  for  data 
processing  personnel  and/or  data  processing  terms 
defined  for  the  user--and  the  documentation 
distribution  index  and  the  system  test  plan. 

Documentation  Distribution  Index 

The  documentation  distribution  index  provides  a  vehicle 
for  reproducing  portions  of  the  master  documentation 
file  for  inclusion  in  the  system  development  working 
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documentation  and/or  the  user  and  data  processing 
operations  manuals. 

Figure  20.1  is  an  index  of  the  contents  of  the  master 
documentation  file.  The  second  and  third  columns  are 
for  the  portions  of  the  documentation  that  are  to  be 
included  in  the  user  and  data  processing  operations 
manual.  Note  that  under  "User  Description"  is  listed 
"User  Operations  Manual,"  and  under  "Data  Processing 
Instructions,"  "Data  Processing  Operations  Manual." 
These  entries  refer  to  any  remaining  operating 
documentation  required  after  the  reproduced  portions  of 
the  master  documentation  file  are  included. 
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409       OBJECTIVE — To  Provide  Data  Processing  Orientation  and 
Training  to  SRS  Staff  at  All  Organizational  Levels 

A  training  program  for  users  and  potential  users 

(administrators,  bureau  chiefs,  and  selected  section 

supervisors   and   technicians)  should   include   the 
following  topics. 

°  Project  responsibility  -  user  vs.  DP 

"  Project  planning  -  who  does  what,  when 

"  Feasibility  study  -  should  it  be  done 

**  Cost  benefit  analysis  -  is  it  cost  justified 


o 


o 


o 


Developing  goals  and  objectives  for  the  system  - 
what  is  to  be  accomplished 

Defining  functions  and  requirements  of  the 
system  -  user  and  DP  involvement  in  developing 
input-output  requirements 

Analyzing  existing  procedures  -  how  do  we  do  it 
now 
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"  Conversion  -  who  and  what  is  involved 

**  Implementation  -  what  has  to  be  done,  by  whom 

°  Training  user  staff  -  who,  what  and  when 

"  On-line  vs.  batch  -  what  are  they 

°         User  manuals  -  what  are  they,  their  purpose,  who 
develops  and  maintains 

The  training  program  should  be  designed  for  two 
levels  -  Upper  Management  orientation  and  Direct  User 
training.  It  should  be  specific  enough  to  be 
informative,  but  should  not  attempt  to  make  everyone  a 
"DP  expert" .  We  should  use  our  in-house  resources  to 
conduct  the  training  to  the  maximum  extent  possible; 
however,  if  outside  expertise  is  required,  it  should  be 
nonacademic.  The  training  should  be  SRS  worker 
oriented  rather  than  theory. 

A  portion  of  this  training  package  should  be  included 
in  an  ongoing  new  employee  orientation  program 
(particularly  for  those  employees  located  in  the  SRS 
building) . 
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The  DP  training  package  should  be  developed  by  Staff 
Development  and  reviewed  for  approval  by  the  DP  Task 
Force  before  finalization. 

410       OBJECTIVE — Provide  Adequate  Security  for  Information 
Contained  in  Computer  Systems 

Data  contained  in  department  DP  systems  must  be  secured 
from  unauthorized  access  to  the  system,  both  physically 
and  electronically.  Security  is  accomplished  by 
limiting  physical  access  to  computer  hardware  via 
locating  equipment  in  an  area  where  physical  security 
can  be  enforced,  locking  terminals,  etc.  Passwords, 
sign  on/off  procedures,  access  codes,  etc.,  are 
examples  of  security  from  electronic  penetration. 

The  degree  of  security  should  be  commensurate  with  the 
sensitivity  of  the  data  in  each  system;  however,  all 
systems  should  prevent  unauthorized  access  to  thwart 
unauthorized  data  manipulation. 

When  employees  terminate,  the  passwords  should  be 
deleted.   Keys  should  be  stored  in  a  secure  place. 


GSl/T 
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SECTION 

REQUESTING   DATA  PROCESSING  SERVICES 


1201 


SUBJECT 


Form  SRS-DP-39: 
ment  Request" 


'New  Systems  Develop- 


INSTRUCTIONS  FOR 
COMPLETING   FORM: 


It  is  the  responsibility  of  the  Data  Processing  Bureau  to  provide 
initial  cost  estimates  and  resource  requirements  for  the  implemen- 
tation end  ongoing  support  of  the  request.  The  Data  Processing 
Bureau  will  schedule  the  work  on  each  request  depending  upon 
priorities  established  by  the  DPMP  Steering  Committee. 

It  is  the  responsibility  of  the  DPAVP  Steering  Committee  to  re- 
view, approve/disapprove  requests  and  assign  a  project  priority 
to  each  request. 

DISTRIBUTION  - 

Requestor  —  Upon  completion  of  items  1  through  9,  the  goiden- 
rod  copy  shall  be  retained  by  the  originator.  All  other  copies 
will  be  sent  to  the  Data  Processing  Coordinator. 

Data  Processing  Coordinator  —  Upon  completion  of  follow-up 
interviews  with  the  requestor,  all  copies,  along  with  all  asso- 
ciated attachments,  will  be  sent  to  the  Data  Processing  Bureau, 

Data  Processing  Bureau  —  Upon  completion  of  items  10  through 
14,  all  copies,  along  with  all  associated  attachments,  will  be 
sent  to  the  Data  Processing  Coordinator. 

Data  Processing  Coordinator  —  Upon  completion  of  items 
15  and  16,  the  original  will  be  sent  to  the  Data  Processing 
Bureau.  The  yellow  copy  will  be  returned  to  the  originator 
and  the  pink  copy  shall  be  retained  by  the  Data  Processing 
Coordinator. 


Responsibility 


•  Requestor 


ACTION: 

FORM  SRS-DP-39:  "NEW  SYSTEMS  DEVELOPMENT  REQUEST" 


© 
© 


Enter  the  name  of  the  division,  bureau,  unit,  etc.,  request- 
ing the  services. 

Enter  a  brief  description  of  the  type  of  development  (e.g., 
"New  Time  Reporting  System",  "Recipient  Restriction 
Sub-System",  etc.). 
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SECTION 


REQUESTING   DATA  PROCESSING  SERVICES 


m 


•  Administrator 

•  Data  Processing  Bureau 


O 


© 
© 


© 


© 


© 


■.IIIJECT 


Form  SRS-DP-39: 
ment  Request" 


'New  Systems  Develop- 


If  the  development  is  to  become  a  part  of  an  existing 
SRS  system,  enter  the  system  name  and  system  number. 

Specify  the  general  Goals  and  Objectives  of  the  request. 
(E.g.,  Goal:  provide  an  effective  on-line  Montana  Income 
Maintenance  System  that  would  support  the  needs  and 
priorities  of  the  Economic  Assistance  programs.  Objectives: 
reduce  error  rates,  improve  management  and  statistical 
data,  provide  a  payment  system,  etc.) 

Define  the  requirements  of  the  system  (e.g.,  an  on-line 
client  tracking  system  with  approximately  12,000  clients, 
monthly  reporting  and  on-line  update).  Identify  require- 
ments which  are  mandatory  to  the  system,  requirements 
which  are  flexible  {alternatives  would  be  acceptable),  re- 
quirements which  could  be  deferred  until  a  later  date  and 
requirements  which  are  only  desirable. 

Give  the ,  reasons  why  this  request  would  be  beneficial. 
For  example,  compliance  with  Federal  or  State  require- 
ment. Department  policy,  increased  accuracy  of  infor- 
mation, quantity  of  information,  timeliness  of  informa- 
tion, etc.  Also,  identify  any  privacy  or  security  require- 
ments    imposed     by     legislation     or    Department    policy. 

Enter  the  desired  completion  date  and  responsibility 
center  code  number  for  data  processing  operational 
expenses. 


(s)      Sign  your  name  and  enter  your  phone  number. 
(9)      Sign  and  date. 


Project  Estimates,  Items  '(^OJ  through  (l2)  are  based  on  general 
information  contained  in  the  "New  Systems  Development  Request" 
and  attachments.  They  are  to  be  considered  as  rough  estimates 
only  and  subject  to  change  as  additional  detail  information  becomes 
available  or  the  scope  of  the  project  changes. 

Enter  the  total  number  of  hours  required  by  the  Data  Pro- 
cessing Bureau  to  complete  this  project  and  the  total  de- 
velopment cost  of  the  project  based  on  $20  per  hour. 
Estimate  should  include  time  for  the  following: 
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REQUESTING  DATA  PROCESSING  SERVICES 


SUBJECT: 


Form  SRS-DP-39: 
mant  Request" 


'New  Systems  Develop- 


r> 


® 


•  Data/Processing/Word  Processing^-. 
Steering  Committee  (ib) 


•  Project  control 

®  Systems  analysis  and  design 

©  Programming  and  testing 

®  User  training 

®  implementation/conversion 

Based  on  $15  per  hour,  enter  the  annual  operational  costs. 

Enter  the  annual  computer  processing  costs. 

Based  on  current  projects,  their  priorities  and  available 
resources,  enter  an  estimated  start  and  completion  date. 
These  dates  are  subject  to  change  and  can  be  affected  by: 
changes  in  the  scope  of  the  project,  new  higher  priority 
projects  resulting  from  new  legislation  or  Department 
policy  and  other  emergencies. 

1 

Determine,  based  on  the  scope  of  the  request,  system  re- 
quirements, resource  and  cost  factors  if  a  further  (more 
detailed)  feasibility  study  is  required. 

Data  Processing  Bureau  Chief  Signature  and  Date. 


Approve/disapprove  request  based  on  information  sub- 
mitted by  the  Data  Processing  Coordinator,  Data  Pro- 
cessing Bureau  Chief  and  a  presentation  by  the  user  of 
his/her  request. 

Assign  a  project  priority  from  1  to  10  based  on  the  size 
of  the  development  request,  need,  impact  on  other  projects 
currently  in  progress  and  available  resources. 


Low  Priority 
Average  Priority 
High  Priority 
Critical  System 
Emergency  Request 


1-3 

4-6 

7-8 

9 

10 


r\ 


16 )       DP/WP  Steering  Committee  Chairman  Signature  and  Date. 
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SECTION 


SUBJECT 


REQUESTING   DATA  PROCESSING  SERVICES]       Form  SRS-DP-39:   "New  Systems  Development 

Request" 


J. 


REDUCED  COPY  OF    FORM  SRS-DP-39:   "NEW  SYSTEMS   DEVELOPMENT   REQUEST" 


€> 


C^ 


SRS-OP-39 


MONTAN^K  OEPT.  ilT   SOCI/"  L  &    REHABILITATION  SERVICES 
Centralized  Servicei  DiviKon 


TO:   Dala  Processing  Coordinator 
Centralized  Services  Division 


NEW  SYSTEMS 
DEVELOPMENT 
REQUEST 


Subject; 


m 


FROM: 


© 


System 


M 


Goals  Et  Objectives: 


I    !  see  ^nachn^ents 


System  Requirements  /  DesireJ  Results: 

■  © 


I    \see  anachi-ents 


Reason  /Justification  for  Request: 


© 


Requested  Completion  Date   \J_J_ 
Originator's  signature:    (  8  ) 


1 ]  see  attachments 


Approved  by 


Chargeable  resp.  center: 

Phone  No: 

Date: 


fOR   OA  TA   PROCESSING    USE   ONL  Y, 


'roject  development  eslimate  Hours:    

Annual  operational  costs:     Maintenance:   

Annual  Computer  Processing  Costs:         Storage: 
I  Estimated  start  date: 


Cost: 


Data  Entry: 


Comp.  Operations: 


Processing: 


Completion  date: 


Feasibility  study  required:      Q]  Ves      Q  No       By: 


Date 


DATA   PROCESSING  /WORD  PROCESSING   STEERING   COMMITTEE 


Request:  (IB)  Q  Approved  for  in  house  development 
Priority  Assigned: 


Q  Contract  Development  |    |  Disapproved 


By:      (16 


Dale 


Project  No 


DlSTMlBUtlON  Ofifinil      OP  lluf'U  Vrllow      ArknOMlM9*m«nl  Coi<v  MnK         DP  Cobrd<n^lO'  CoM'''>-o<l       Mmjiu-.-  -     Copr 
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DEPARTMENT   OF   SOCIAL   AND 
REHABILITATION   SERVICES 


ADMINiSTRATIV 
NUAL 


ADM 


1201 


SECTION 


REQUESTING  DATA  PROCESStNG 
SERVICES 


SUBJECT 


Form     SRS-DP-39: 
Development  Request' 


"New    Systems 


FORM  SRS-DP-39: 
"NEW  SYSTEMS 
DEVELOPMENT  REQUEST": 


f^ 


CHARACTERISTICS  &  PURPOSE  -  Form  SRS-DP-3D,  "New 
Systems  Development  Request"  (see  page  5  for  a  reduced  copy), 
is  on  4-part  carbonless  paper.  It  is  used  to  request  new  data  pro- 
cessing systems  development  or  major  changes  to  existing  SRS 
data  processing  systems.  This  form  is  not  intended  to  capture  all 
of  the  detailed  information  required  for  a  complete  understand- 
ing of  the  request.  It  does,  however,  provide  a  capsule  look  at  the 
economics  of  the  proposed  project  and  a  basis  for  continued  re- 
view, approval  or  disapproval.  It  also  provides  criteria  by  which 
management  can  evaluate  and  set  priorities  for  new  projects. 

RESPONSIBILITY  -  It  is  the  responsibility  of  the  requestor  to 
initiate  this  form 'and  submit  it,  along  with  any  attachments,  to 
the  Data  Processing  Coordinator.  The  appropriate  Administrator 
must  review  and  approve  each  request  prior  to  its  submission  to 
the  Data  Processing  Coordinator.  The  requestor  will  also  be  re- 
sponsible for  giving  a  presentation  of  his/her  request  to  the  DP/ 
WP  Steering  Committee  prior  to  approval/disapproval. 

It  is  the  responsibility  of  the  Data  Processing  Coordinator  to  re- 
view ihe  request  for  overall  content,  feasibility  and  practicality. 
The  Data  Processing  Coordinator  will  conduct  follow-up  inter- 
views with  the  requestor/user  to: 

•  Insure  all   user   requirements  have  been   identified,   that  they 
have  been  adequately  researched  and  clearly  stated. 

•  Review  alternatives  to  the  proposed  request. 

•  Further    identify    input,   output   and    processing   requirements. 

•  Review    relationships  to  other  requests,   projects  and   depart- 
ment programs. 

0     Identify  internal  or  external  constraints. 

•  Identify  ■  organizational    effects/changes   as  a   result  of   imple- 
menting the  request. 

•  Review  other   areas   which   are   required   for  a  comprehensive 
understanding  of  the  request. 
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(  DEPARTMENT  OF  SOCIAL  AND 

REHABILITATION  SERVICES 

ADMINISTRATIVE 
MANUAL 


SECTION: 


REQUESTING  DATA  PROCESSING 
SERVICES 


SUBJECT: 


Form  SRS-DP-29,  "System 
Support/Enhancement  Request" 


o  ■ 

00 


^   FORM  SRS-DP-29, 
'-*   "SYSTEM  SUPPORT/ 
c  ENHANCEMENT 
^   REQUEST": 


CHARACTERISTICS  AND  PURPOSE--Form  SRS-DP-29, 
"System  Support/Enhancement  Request"  (see  page  3 
for  a  reduced  copy),  is  in  four  parts  on  carbon- 
less paper.   It  is  used  to  request  changes  or 
enhancements  to  existing  SRS  data  processing 
systems.   This  form  shall  not  be  used  to  request 
new  systems  development. 

RESPONSIBILITY — It  is  the  responsibility  of  the 
requestor  to  initiate  this  form  and  submit  it  to 
the  Data  Processing  Bureau.   The  appropriate 
Administrator  must  review  and  approve  each 
request  prior  to  its  submission  to  the  Data 
Processing  Bureau. 

It  is  the  responsibility  of  the  Data  Processing 
Bureau  to  schedule  each  request  on  a  "first 
come,  first  served"  basis  except  for  priorities 
established  by  the  SRS  Policy  Committee. 

DISTRIBUTION-- 

Requestor — upon  completion  of  items  1 
through  7,  the  original,  yellow  and  pink 
copies  will  be  sent  to  the  Data  Processing 
Bureau.   The  gold  copy  shall  be  retained  by 
the  originator. 

Data  Processing  Bureau — upon  completion  of 
Ttiin  8,  the  Data  Processing  Bureau  shall 
return  the  yellow  copy  to  the  ori-ginator. 
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REQUESTING  DATA 
PROCESSING  SERVICES 


ADM 


1201-2 


SUBJECT: 


Form  SRS-DP-29,  "System 
Support/Enhancement  Request' 


Requestor 


O 


1.  Enter  the  name  and  mailing  address  of  the 
unit  (Division,  Bureau,  etc.)  requesting 
the  services. 

2.  Enter  a  brief  description  of  the  nature  of 
the  request  (i.e.,  "Add  MIMS  Report", 
"Modify  BENDEX  Edit",  etc.). 

3.  Enter  the  system  name  and  system  number. 

4.  Describe  the  nature  of  the  request  briefly, 
but  specifically,  outlining  what  service  is 
required.   Include  report  names,  job 
numbers,  equipment  types,  or  anything  that 
will  help  further  define  the  services 
requested.   Attach  illustrations,  sample 
reports,  or  examples  of  problems,  if  possi- 
ble.  Also  include  a  date  by  which  the 
request  should  be  completed. 

5.  Give  the  reasons  why  accomplishing  the 
request  would  be  beneficial.   Examples  are 
to  correct  a  design  deficiency  or  program 
problem,  improve  turnaround,  eliminate 
manual  work,  more  timely  reporting,  state 
or  federal  requirement.   Also,  attach  any 
documentation  that  would  further  illustrate 
these  benefits. 


Administrator 


Sign  your  name  and  enter  your  phone  number. 

Sign  and  date.   This  division  will  be  the 
responsible  user  for  the  project. 


Data  Processing 
Bureau 


After  an  initial  review  and  evaluation,  a 
work  plan  outlining  the  tasks  to  be 
accomplished  and  a  schedule  for  completion 
will  be  established  if  possible  (larger  or 
more  complex  requests  may  require  follow-up 
meetings  with  the  requestor  before  a  final 
plan  can  be  presented). 
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StCTION: 


REQUESTING  DATA 
PROCESSING  SERVICES 


SUBJECT: 

Form  SRS-DP-29,  "System 
Support/Enhancement  Request" 


9  If,  upon  receipt  of  the  yellow  copy  from 
the  Data  Processing  Bureau,  the  scheduled 
completion  date  does  not  satisfy  the 
requestor's  needs,  the  appropriate  Admini- 
strator may  present  the  request  to  the  SRS 
Policy  Committee. 

10  The  SRS  Policy  Committee  may  establish 
priorities  for  DP  System  Support/Enhance- 
ment Requests  after  considering  other  work 
in  progress  and  requests  received  by  the  DP 
Bureau. 

SEE  NEXT  PAGE  FOR  REDUCED  COPY  OF 
FORM  SRS-DP-29 
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APPENDIX  "C" 


STATE  OF  MONTANA 
Data  Processing 
PoUcies,  Standards,  and  Guidetoes- 
Issued  By  The 
Governor's  Office 
of 
Budget  and  Program  Planning 


(L-i 


OFFICE  OF  THE  GOVERNOR 

BUDGET  AND  PROGRAM  PLANNING 


TEDSCHWINDEN  GOVERNOR 


STATE  OF  MONTANA' 


140S)449-36I6 


CAPITOL  BUILDING 


HELENA.  MONTANA  59620 


DPM  NBR  1 


TO:  All  State  Agencies 

FROM;        Troy  W.  McGee 

Data  Processing  Coordinator 

DATE;        June  1,   1981 

RE:  INTRODUCTION  TO  DATA  PROCESSING  MEMOS 


This  is  the  first  in  a  series  of  memos  which  will  be  issued  by  the  Office 
of  Budget  and  Program  Planning  relating  to  policies,   standards,  and  guidelines 
for  the  management  of  data  processing  in  state  government.      Authority  for 
these  memos  is  contained  in  Management  Memo  4-81-2  in  compliance  with  Section 
18-4-111,  MCA.     Each  memo  in  this  series  will  attempt  to  deal  concisely  with  a 
specific  subject  in  order  to  reduce  the  possibility  of  confusion  or  conflicts 
and  provide  immediate  and  broad  exposure. 

To  provide  ready  reference  and  ease  of  updating,  it  is  recommended  that 
these  memos  be  kept  in  a  three  ring  binder  in  numeric  order. 

Your  efforts  to  comply  with  these  policies,   standards,  and  guidelines  will 
be  appreciated.     However,   it  should  be  understood  that  compelling  reasons, 
such  as  changes  in  technology,  may  require  modifications  from  time  to  time.  ■ 
Any  questions  or  concerns  regarding  these  memos  should  be  directed  to  the 
Dale  Processing  Coordinator  in  the  Office  of  Budget  and  Program  Planning. 
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OFFICE  OF  THE  GOVERNOR 

BUDGET  AND  PROGRAM  PLANNING 


TED  SCHWINDEN  GOVERNOR 


STATE  OF  MONTANA' 


(406)449  3616 


CAPITOL  BUILDING 


HELENA,  MONTANA  59620 


DPM  NBR  2 


TO:  All  State  Agencies 

FROM:         Troy  W.   Mc.Gse 

Data  Processing  Coordinator 

DATE:        June  1,    1981 

RE:  CONTRACTING  FOR  PROFESSIONAL  PERSONAL  SERVICES 


1 


Ultimately,  each  agency  is  responsible  for  the  design,''  development,   and 
support  of  their  data  processijig  systems.     For  many  reasons,   it  is  highly 
desirable  that  these  efforts  be  performed  in-house  under  the  direct  super- 
vision and  management  control  of  the  agency       However,   in  a  number  of 
instances,  it  may  be  desirable  or  necessary  for  these  efforts  to  be  performed 
by  others.     The  following  policies  have  been  established  regarding  this  matter: 

The  Department  of  Administration,   Information  Systems  Division 
shall  be  the  first  choice  when  contracting  for  professional  personal 
services  related  to  automated  information  systems. 

When  the  Information  Systems  Division  is  unable  to  provide  the 
necessary  services,  contracting  with  the  private  sector  may  be 
appropriate. 

It  is  necessary  to  document  the  fact  that  neither  the  agency  nor  the 
Information  Systems  Division  can  provide  the  services  before  any  effort  is 
made  to  contract  with  the  private  sector.     To  reduce  the  potential  for  wasted 
effort,   the  approval  to  proceed  should  be  obtained  from  this  office  in  advance. 
A  procurement  justification  form  (revised  March  13,    1981)  for  data  processing 
eciuipment  and  software  should  be  used. 

When  developing  a  professional  personal  services  contract,   the  services 
to  be  provided  and  the  product  to  be  delivered  must  be  clearly  and  fully 
specified.     Except  for  emergency  situations  and  extenuating  circumstances, 
whenever  it  is  reasonably  foreseeable  that  a  proposed  contract  for  these 
professional  services  will  exceed  $5,000,   the  agency  must  request  quotations 
from  all  private  consultants  who  have  requested  to  be  placed  on  the  State 
Purchasing  Division. bid  list. 
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To  assure  management  control  of  large  projects,   it  is  vital  that  the 
services  be  contracted  in  phases.     It  is  recommended  that  a  mmimum  of  three 
phases  be  established,  consisting  of  planning  (this  includes  the  system  re- 
quirements and  external  design),   development  (this  includes  internal  design 
program  development,   system  test  and  system  installation)  and  support,     hach 
phase  would  be  a  separate  contract  with  appropriate  deliverables  defined. 
Further  guidance  on  this  subject  can  be  obtained  from  the  Customer  Information 
Guide  developed  by  the  Information  Systems  Division. 

Once  a  contractor  has  been  selected,   it  is  necessary  to  establish  a 
contract  agreement.     A  standard  contractual  agreement  for  Computer  Software 
Development  has  been  established.     A  copy  of  this  Standard  Contract  is 
attached  and  will  be  used  if  at  all  possible,   as  it  is  then  less  likely  that 
required  contractual  language  will  be  omitted. 

Finally,  no  contract  for  professional  services  related  to  data  processing 
will  be  executed  without  the  prior  approval  of  the  Data  Processing  Coor- 
dinator. 
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STATE  OF   MONTANA 
STANDARD  COMPUTER  SOFTWARE   DEVELOPMENT  CONTRACT 


This  AGREEMENT  is  made  by  and  between  the  State  of  Montana, 


(herein  referred  to  as  DEPARTMENT)  and 


therein  referred  to  as  CONTRACTOR).  The  main  purpose  of  this  AGREEMENT  is 


Both  the  DEPARTMENT  and  the  CONTRACTOR  agree  to  the  terms  and  conditions  specified  in 
this  AGREEMENT. 

SECTION  I  -  CONTRACTOR  SERVICES.  The  Contractor  warrants  that  the  results  of  this 
Contract  will  meet  the  functional  and  performance  specifications  and  standards  described  in 
Schedule  "A". 

SECTION  II  -  PERFORMANCE.  Upon  completion  of  the  work  described  in  Schedule  "A",  any 
tests  as  outlined  in  Schedule  "A"  shall  be  performed  at  the  department  site  with  departmental 
data  to  determine  whether;  a)  the  products  meet  specifications  and  st-andards  described  in  this 
Contract  and  (b)  that  they  perform  repetitively  on  a  variety  of  data  without  failure.    If  any  test 

discloses  deficiencies,  the  Contractor  shall  within days  correct  such  deficiencies  and  the 

Department  thereafter  has  an  additional days  to  conduct  new  tests.    Following  successful 

completion  of  each  test  the  Department  shall  notify  the  Contractor  of  acceptance. 

SECTION  III  •  WORK  IN  PROGRESS.  It  is  agreed  that  the  Department  shall  have  the  right  to 
inspect/review  all  work  in  progress. 

SECTION  IV  -  DEPARTMENT  ASSISTANCE.  The  Department  agrees  and  promises  to  provide 
assistance  to  the  Contractor  as  follows: . — 


SECTION  V  -  COMPENSATION.  In  consideration  for  services  rendered  pursuant  to  this 
AGREEMENT,    the    Department   agrees   to    pay    the   Contractor    an    amount    not   to  exceed 

$ as  detailed  m  Schedule  "B".  No  additional  charges  shall  be 

claimed  by  the  Contractor  for  any  goods  or  services  including  source  documentation,  error  cor- 
rection, upgrades,  maintenance  or  expenses  for  any  other  material  or  service  to  be  performed 
under  this  AGREEMENT. 

SECTION  VI  -  EFFECTIVE  DATE  AND  DURATION.    This  Agreement  shall  take  effect  as  of 

and  shall  terminate . 

unless  terminated  earlier  pursuant  to  Section  XV. 
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STATE   OF   MOMTANA 
STANDARD  COMPUTER  SOFTWARE   DEVELOPMENT  CONTRACT 


SECTION  VII  -  ASSIGNMENT  AND  SUBCONTRACTING.  The  Agreement  may  not  be  assigned 
by  the  Contractor  nor  may  the  Contractor  permit  anyone  other  than  the  Contractor's  personnel  to 
perform  any  of  the  work,  servicuj  or  other  performance  required  of  the  Contractor  under  this 
Agreement  without  the  prior  written  consent  of  the  Department. 

SECTION  Vill  -  OWNERSHIP  AND  PUBLICATION  OF  MATERIALS.  The  Contractor  shall 
provide  to  the  Department  all  documentation  as  deemed  necessary  by  the  Department  for  the 
system  resultant  from  partial  or  full  performance  of  this  Agreement.  This  documentation  shall 
meet  standards  acceptable  to  the  Department.  The  Department  shall  retain  ownership,  for  all 
purposes,  of  working  papers,  working  products  and  end  products.  However,  the  Contractor  shall 
retain  possession  of  those  records  required  by  Section  XIV  of  this  Contract  for  three  (3)  years 
after  termination  of  this  Agreement. 

SECTION  IX  -  WARRANTIES.  The  Contractor  warrants  that  the  software  delivered  as  per 
Schedule  "A"  of  this  Contract  is  free  of  defects  and  will  meet  the  specifications  described  herein. 
The  Contractor  further  agrees  to  correct  any  defects  free  of  charge  for  a  period  of  three  months 
after  acceptance  by  the  Department.  This  provision  shall  not  apply  to  problems  caused  by  actions 
of  Department  personnel  or  equipment. 

SECTION  X  •  VENUE.  The  Department  and  the  Contractor  agree  that  venue  for  any  court  action 
arising  under  this  Agreement  shall  be  in  the  First  Judicial  District  in  and  for  Lewis  and  Clark 
County,  Montana.  Further,  the  Department  and  the  Contractor  agree  that  this  Agreement  shall  be 
interpreted  according  to  the  laws  of  the  State  of  Montana. 

SECTION  XI  -  INDEPENDENT  CONTRACTORS.  It  is  agreed  that  the  Contractor  is  an  inde- 
pendent contractor  and  not  an  employee  of  the  State  of  Montana.  Because  the  Contractor  is  an 
independent  contractor  under  the  terms  of  this  Agreement,  the  Department  shall  not  deduct  from 
the  Contractor's  compensation  to  make  payment  for  any  federal,  state  or  municipal  taxes.  The 
Contractor  shall  pay  all  federal,  state  and  municipal  taxes  which  may  be  required  on  the  compen- 
sation paid  under  this  Agreement.  Also,  the  Contractor  and  its  employees  are  not  covered  by  the 
Worker's  Compensation  Laws  as  applicable  to  the  Department  as  the  employer. 

SECTION  XII  ■  BONDS.  If  the  Department  determines  that  a  bond  is  necessary,  it  is  hereby  agreed 
that  the  Contractor,  upon  adequate  and  due  notice  from  the  Department  prior  to  consummation 
of  this  Agreement,  will  supply  sufficient  bond,  provided  by  a  reputable  and  established  surety 
company  or  other  method  approved  by  the  State  of  Montana,  the  terms  of  which  will  be  estab- 
lished by  the  Department. 

A  copy  of  said  bond  shall  be  filed  with  the  County  Clerk  and  Recorder  for  Lewis  and  Clark 
County,  and  other  Counties  where  such  work  is  performed. 

SECTION  XIII  -MODIFICATION.  This  Agreement  constitutes  the  entire  Agreement  between  the 
parties  with  re^Ject  to  the  subject  matter  and  statements,  promises,  or  inducements  made  by 
either  party,  which  are  not  contained  in  this  Agreement  are  neither  valid  nor  binding.  No  amend- 
ment to  this  Agreement  shall  be  effective  unless  it  is  in  writing  and  signed  by  duly  authorized 
representatives  of  both  parties. 


PAGE   2  OF  4 


OBPP  New  6/81 


a-i. 


STATE  OF   MONTANA 
STANDARD  COMPUTER  SOFTWARE  DEVELOPMENT  CONTRACT 


SECTION  XIV  -  RECORDS  BY  CONTRACTOR.  The  Contractor  agrees  and  promises  to  keep  and 
maintain  reasonable  records  of  activities  performed  under  this  Agreement,  and  allow  access  to 
these  records  by  the  Department  and  the  Legislative  Auditor  as  required  by  MCA  5-12  and  13. 
The  Department,  Legislative  Auditor,  or  their  representatives,  shall  have  the  right  to  access  any 
records  of  the  Contractor  which  are  pertinent  to  the  services  provided  under  this  Agreement,  and 
such  records  shall  be  retained  by  the  Contractor  for  no  less  than  three  (3)  years  after  the  termi- 
nation of  the  Agreement. 

SECTION  XV  •  TERMINATION.  Either  party  may  terminate  this  Agreement  without  cause  30 
days  after  delivery  of  written  notice  in  hand  to  the  other  party.  Further,  the  Department  may 
terminate  this  Agreement  for  cause  10  days  after  delivery  of  written  notice  in  hand  to  the 
Contractor. 

Upon  termination,  the  Department  agrees  to  pay  the  Contractor  according  to  the  provisions  of 
Schedule  "8" . 


All  amounts  owed  to  the  Contractor  by  the  Department  at  termination  may  be  reduced  by  the 
amount  of  actual  and  consequential  loss  to  the  Department  due  to  detrimental  reliance  on  this 
Agreement  by  the  Department.  The  Contractor  agrees  to  return  all  properties  including  copies  of 
programs,  documentation,  files,  intermediate  materials  and  related  supplies  upon  the  demand  of 
the  Department. 

The  Contractor  understands  and  agrees  that  the  Department  is  dependent  upon  Federal  and  State 
appropriations  for  its  funding,  and  that  actions  by  Congress  or  the  Montana  Legislature  may  pre- 
clude funding  this  Agreement  completely  through  the  termination  date  stated  in  Section  VI. 
Should  such  a  contingency  occur,  the  parties  may  agree  to  a  new  termination  dataor  terminate  the 
Agreement  immediately. 

SECTION  XVI  -  EQUAL  EMPLOYMENT  OPPORTUNITY.  Pursuant  to  Sections  49-2-303  and 
49-3-207,  Montana  Code  Annotated,  no  part  of  this  Agreement  shall  be  performed  in  a  manner 
which  discriminates  against  any  person  on  the  basis  of  race,  color,  religion,  creed,  political  ideas, 
sex,  age,  marital  status,  physical  or  mental  handicap,  or  natural  origin  by  the  persons  performing 
the  Agreement.  Any  hiring  shall  be  on  the  basis  of  merit  and  qualifications  directly  related  to  the 
requirements  of  the  particular  position  being  filled. 

SECTION  XVII  -  FAIR  LABOR  STANDARDS.  The  Contractor  agrees  to  comply  with  all  appli- 
cable Federal  and  State  wage  and  hour  rules,  statutes  and  regulations,  and  warrants  that  all  appli- 
cable Federal  State  fair  labor  standards  provisions  will  be  complied  with,  both  by  the  Contractor 
and  any  sub-contractor  hired  by  the  Contractor,  in  the  event  that  sub-contracted  services  to  fulfill 
the  terms  and  conditions  of  this  Agreement  are  agreed  upon  by  the  Department  and  the 
Contractor. 

SECTION  XVIII  •  SEVERABILITY.  It  is  understood  and  agreed  by  the  parties  hereto  that  if  any 
item  or  provision  of  this  Agreement  is  held  to  be  illegal  or  in  conflict  with  any  Montana  Law,  the 
validity  of  the  remaining  terms  and  provisions  shall  not  be  affected,  and  the  rights  and  obligations 
of  the  parties  shall  be  construed  and  enforced  as  if  the  Agreement  did  not  contain  the  particular 
term  or  provision  held  "to  be  invalid.  Further,  the  parties  agree  to  meet  within  30  days  and  ne- 
gotiate an  acceptable  replacement. 
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STATE   OF   MONTANA 
STANDARD  COMPUTER  SOFTWARE   DEVELOPMENT  CONTRACT 


SECTION  XIX  -  INDEMNIFICATION.  The  Contractor  agrees  that  it  will  indemnify  the 
Department  and  hold  it  harmless  from  any  and  all  losses  that  may  result  to  the  Department 
because  of  negligence  on  the  part  of  the  Contractor,  its  agents,  representatives,  or  employees. 
The  Contractor  shall  hold  harmless  the  Department  from  any  and  all  claims  arising  out  of  the 
execution  of  this  Agreement  for  injury  to  third  persons,  including  their  agents,  employees  or 
volunteers,  recipients,  and  to  the  public  at  large,  for  injury  to  property  or  persons  which  arise  out 
of  any  Contractor's  actions. 

SECTION  XX  -  NOTIFICATION.  It  is  understood  that  Contractor  will  notify  the  Authorized 
Agency  of  the  Department  immediately  upon  determination  that  any  malady  or  occurrence  has 
taken  place  which  would,  in  any  way  affect  or  alter  the  duties,  responsibilities,  authorities,  re- 
lationships or  ability  of  the  Contractor  to  fulfill  the  provisions  of  this  Agreement  in  a  timely 
m.anner  and  as  prescribed  herein. 


SECTION  XXI  ■  LIAISON.  The  Department  designates 

as  liaison  for  Contractor  under  this  Agreement.  Contractor  agrees  to  make  all  official  contacts 
with  Department  with  this  designee,  or  such  other  person  as  the  designee  appoints. 

SECTION  XXII  •  EXECUTION.  Each  party  has  full  power  and  authority  to  enter  into  and  per- 
form this  Agreement,  and  the  person  signing  this  Agreement  on  behalf  of  each  party  has  been 
properly  authorized  and  empowered  to  enter  into  this  Agreement.  Each  party  further  acknow- 
ledges that  it  has  read  this  Agreement,  understands  it  and  agrees  to  be  bound  by  it. 

By  and  For 

CONTRACTOR:       


Signature 


Date 


Name 


Title 


Address 


City 


State 


Representing 


Social  Security  Number  or  Federal  Employer  I.D.  Number 


By  and  For 
DEPARTMENT: 


Signature 


Date 


Name 


Title 


Representing 


Data  Processing  Coordinator 

Office  of  Budget  and  Program  Planning 


Approved  as  to  Form  -  Attorney 
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STATE  OF  MONTANA 
STANDARD  COMPUTER  SOFTWAf.E   DEVELOPMENT  CONTRACT 


SCHEDULE "A" 

This  schedule  provides  functional  and  performance  specifications  standards  and  time  tables  war- 
ranted in  Section  I  of  AGREEMENT  between  . 


and 


dated 


as  follows: 
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STATE  OF  MONTANA 
STANDARD  COMPUTER  SOFTWA-E  DEVELOPMENT  CONTRACT 


SCHEDULE "B" 

This    schedule    provides    detail    concerning    the    compensation    indicated    m    Section    V    of 
AGREEMENT  between  ^ 

and 

dated  


as  follows; 
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BUDGET  AND  PROGRAM  PLANNING 


TED  SCHWINDEN  GOVERNOR 


CAPITOL  BUILDING 


STATE  OF  MONTANA' 


(406)449-3616 


HELENA. MONTANA  59620 


DPM  NBR  3 


TO:  All  State  Agencies 

FROM:         Troy  W.   McCeo 

Data  Processing  Coordinator 

DATE:         June   1,    1981 

RE:  PROCUREMENT  OF  EQUIPMENT  AND  SOFTWARE 


1 


The  Office  of  Budget  and  Program  Planning  has  the  -responsibility  for 
the  review  and  approval  of  all  data  processing  equipment  and  software.     This 
will  help  absure: 

1.  that  existing  data  processing  resources  are  fully  utilized, 

2.  that  data  processing  procurements  are  in  concert  with  the  estab- 
lished long  range  information  processing  plan,  and 

3.  that  data  processing  procurements  are  coordinated  and  compatible 
with  existing  data  processing  resources. 

A  form  has  been  established  (a  copy  is  attached)  which  standardizes  the 
review  and  approval  process.     This  form  must  be  completed  and  submitted  to 
the  Office  of  Budget  and  Program  Planning  for  approval  before  any  data 
processing  equipment  or  software  can  be  obtained. 

The  purpose  of  this  form  is  to  provide  guidance  for  those  preparing  a 
justification  to  procure  data  processing  equipment  or  software.     Do  not  con- 
fuse this  form  with  a  request  for  quotation  (RFP)  or  the  establishment  of 
specifications.     These  are  separate  subjects  but  are  only  necessary  if  the 
justification  has  been  approved. 

It.  is  difficult  to  provide  definitive  guidance  for  the  degree  of  justifica- 
tion required  in  every  instance.     The  development  of  the  necessary  justifica- 
tion should  never  be  taken  lightly.     It  is  obvious  that  the  addition  of  a 
keypunch  or  terminal  to  an  established  function  where  the  workload  has 
increased  should  be  simple.     And  the  procurement  of  a  large  computer  will 
require  a  comprehensive  justification. 


■4M  eOU*L  OPPORTUHITY  £WP(.OVf « 


'^S'. 


<?-// 


Generally,   the  greater  the  cost  ano  complexity  of  the  procurement,   the 
more  comprehensive  the  justification.     If  one  is  to  err,   it  would  be  best  to 
err  on  the  side  of  a  more  comprehensive  justification.     The  review  and  ap- 
proval process  will  proceed  more  quickly  with  less  total  effort  on  everyone's 
part. 

After  the  justification  has  been  prepared,   it  should  be  attached  to  a 
state  requisition  along  with  the  specifications  and  submitted  to  the  Purchasing 
Division.     The  requisition  and  attached  documents  are  then  transmitted  to  this 
office  for  review  and  approval.     The  requisition  is  then  returned  to  the 
Purchasing  Division,   approved,   approved  conditionally,   disapproved,  or 
disapproved  conditionally.     All  justifications  which  are  either  poorly  done  or 
have  inadequate  justification  will  be  disapproved  conditionally. 

If  the  justification  being  prepared  is  for  a  large  procurement,   say  $25,000 
or  greater,  or  a  new  functional  requirement  is  being  met,   it  would  generally 
be  wise  to  obtain  the  review  and  approval  before  preparing  the  state  requisi- 
tion and  specifications. 

Your  efforts  to  develop  well  documented  justifications  will  be  greatly 
appreciated. 
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STATE  OF  MONTAMA 
QrFICfc  OF  BUDGET  AND  PROGRAM  PLANNING 


/•.■■icv 
l_'-niHrnQ 


Agency  Code 


Procurement  Justification   Form   For 
Data  Processing   Equipment  and  Software 


Agency  Name 


?..  •loiion  ol  Equipmeni  Of  SoHwafe:|  Be  jpecific  tnd  attach  ipecificationi  if  deemed  neceuary. 


rnnoisd  Ini'allation  Date 


Location 


i:if''C?t'0''  ol  Procu'e 


■ment  iFullydetcribe  tf>B  purpose  tor  wtiich  the  Equipment  or  SoftvMore  il  needed.  Workload  Factor?,  Coit  Ber>efiU,  Alterr  suvei,  etc. 
ired  IS  dependent  upon  the  Total  Cost  and  comolexity  of  the  Procurement.  Hovvever,  inadequate  or  poorly  prepared  jujtificaiioni  will 


The  level  of  detail  requ    __    _       . 

<  jt  be  processed.  (Note:  eenerally  the  ipace  alloted  will  not  be  adequate). 


-ompatibility  Requirements; 

Note  eny  requirements  for  compatibility  such 

as.  Equipment,  Software,  Firmware.  Communication  Lines,  etc. 

*.  ■ 

r 

ommunication  Requirements:  |  Diicuil  communication  needs  and  purpose. 

and  if  communicating  with  an  Existing  Host,  obtain  approval  to  connect 

- 

Approval  of  Host  Facility  Official 

vocation  of  Host 

Jr)ips 

- 

Signature                                             Title                                Date 

•  in^x,ti\  In'i'.-maiiorJ 

- 

Budgetary  Details 

Account  Number 

Appropriation  Number 

froposed  Method  of  Procurement 
Q    Rent                                           Annual  Lease  Cost          $ 

Budgeted 

r]    Lease 

L]    Purchase  Time/Pay 

pi     PurrhBte 

Annual  Time/Pay  Cost  S 

Not  Budgeted 

1 

Total  Purchase  Cost        $ 

Anniinl  Maint     Crm             £ 

Funding  Operation 
Expense 

^ 

f       

'XuT*      'ted  Apency  Official 

OHice  of  Budget  and  Program  Planning 

' 

[]     Approved                       □      ApprcA/ed  Conditionally 
□     Disapproved                   Q      Disapproved  Conditionally 

SIgnatura 

Signature 

Title 


Date 


TUle 


Date 
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OFFICE  OF  THE  GOVERNOR 

BUDGET  AND  PROGRAM  PLANNING 


TED  SCHWINDEN.  GOVERNOR 


STATE  OF  MONTANA 


40614493616 


CAPITOL  BUILDING 


HELENA,  MONTANA  59620 


DPM  NBR  4 


TO:  All  State  Agencies 

FROM:         Troy  W.   McGee     ■ 

Data  Processing^  Coordinator 

DATE:         June  1,    l9Si 

RE:  WORD  PROCESSING  EQUIPMENT 


In  April,   1978,    the  state  of  Montana  installed  a  shared  '.vord  processing 
system  on. the  Ceniral  Computer  Facility.     This  system  is  called  the  Advanced 
Text  Management  System  (ATMS  III).      A  shared  word  processing  system  was 
selected  for  many  reasons  but  ultimately  to  assure  that  all  state  agencies 
would  have  access  to  a  high  level  word  processing  service  at  the  least  cost. 

Obviously,   the  state  has  made  a  major  commitment  in  this  area,   in  both 
cost  and  resources,   as  this  is  a  substantial  system  with  all  of  the  normal 
word  processing  capabilities  and  in  addition,   the  major  capabilities  that  only  a 
large  system  can  provide.     Also,   this  system  will  be  conducive  to  the  new 
advancements  which  will  be  experienced  in  word  processing. 

It  is  important  that  this  service  be  used  whenever  applicable  and  must 
be  the  first  consideration  when  contemplating  word  processing  needs.     No 
request  for  word  processing  capabilities  will  be  considered  without  justifying 
the  need  with  a  cost  benefit  analysis  and  a  review  and  evaluation  of  this 
service. 

Generally,   the  approval  of  word  processing  equipment  will  be  contingent 
upon  the  potential  capability  to  communicate  with  the  computer  facility  in  the 
Department  of  Administration.     This  will  assure  that  the  greater  capabilities 
of  y\TMS  can  be  utili7.cd.     (Archival  document  storage  and  retrieval,   high 
speed  printing,   typesetting,   ability  to  transfer  equipment,   etc.) 

As  a  minimum,   the  word  processing  equipment  must  be  capable  of  com- 
municating via  SNA  (System  Network  Architecture)  and  SDLC  (Synchronous 
Data  Link  Control)  without  any  software  modifications  so  that  text  transmitted 
to  the  computer  facility  can  be  processed  under  ATMS.     The  vendor  may  be 
required  to  demonstrate  or  warranty  this  capability.     In  addition,   the  agency 
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may  require  even  greater  communications  capabilities  depending  upon  the 
functional  requirements  of  the  system. 

Further  information  regarding  ATMS  can  be  obtained  by  contacting  the 
Computer  Services  Division,  Department  of  Administration. 


C-/^ 


TEDSCHWINDEN  GOVERNOR 


OFFICE  OF  THE  GOVERNOR 

BUDGET  AND  PROGRAM  PLANNING 


STATE  OF  MONTANA' 


CAPITOL  BUILDING 


HELENA^  MONTANA  59620 


DPM  NBR  5 


TO:  All  State  Agencies 

FROM:         Troy  W.   McGee 

Data  Processing  Coordinator 

DATE:         June  1,    1981 

RE:  AVAILABILITY  OF  STATE  DEVELOPED  COMPUTER  SOFTWARE 

PRIVATE  SECTOR 


It  is  the  opinion  o^  our  legal  staff  that  computer  software  (programs) 
and  the  related  documentation  developed  by  state  agencies  are  the  personal 
property  of  the  state  of  Montana.     Therefore,  computer  software  is  not  to  be 
released  to  the  private  sector  without  the  prior  approval  of  this  office. 
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BUDGET  AND  PROGRAM  PLANNING 


STATE  OF  MONTANA 
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HELENA.  MONTANA  59620 
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TO:  All  State  Agencies 

FROM:         Troy  W.   MoGee 

Data  Processing  Coordinator 

DATE:         June  1,    1981 

RE:  AVAILABILITY  OF  STATE  DATA  PROCESSING  EQUIPMENT 

PRIVATE  SECTOR 
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State  data  processing  equipment  is  not  generally  available  for  use  by  the 
private  sector  as  this  could  produce  an  unfair  competitive  advantage  in  the 
private  sector.     However,   it  is  recognized  that  there  are  certain  circum- 
stances where  the  use  of  state  owned  data  processing  equipment  may  be 
approved  by  the  Data  Processing  Coordinator  within  the  following  guidelines: 

The  capability  to  be  provided  by  the  state  owned  data  processing 
equipment  (excluding  computer  software)  must  not  be  available  in 
the  private  sector  in  Montana. 

The  use  of  state  owned  data  processing  equipment  cannot  have  an 
adverse  effect  on  the  state  data  processing  needs,   nor  can  the  use 
by  the  private  sector  be  used  to  justify  additional  data  processing 
equipment  acquisitions.     Only  excess  time  on  the  data  processing 
equipment  may  be  considered  for  use  by  the  private  sector. 

The  use  of  state  owned  data  processing  equipment  shall  be  discon- 
tinued immediately  when  the  capability  is  available  in  the  private 
sector. 

The  total  cost  associated  with  the  use  of  state  owned  data  proces- 
sing equipment  will  be  passed  on  to  the  individual  for  whom  the 
service  is  provided. 

The  rates  used  in  determining  the  cost  of  providing  the  services 
wiU  be  the  current  published  rates  of  the  Computer  Services  Division 
and  the  Information  Systems  Division  unless  higher  rates  have  been 
determined  to  be  more  aiDpropriate. 
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Nolhinf^  in  this  policy  statement  is  to  be  interpreted  to  preclude  the 
possibility  of  a  state  agency  contracting  with  the  private  sector  for  services 
which  includes  the  use  of  state  owned  data  processing  equipment  in  order  to 
meet  the  terms  of  the  contract. 
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OFFICE  OF  THE  GOVERNOR 

BUDGET  AND  PROGRAM  PLANNING 


TEDSCHWINDEN  GOVERNOR 


STATE  OF  MONTANA' 


(406)449-3616 


CAPITOL  BUILDING 


HELENA.  MONTANA  59620 


DPM  NBR  7 


TO:  All  State  Agencies 

FROM:        Troy  W.   McGce 

Data  Processing  Coordinator 

DATE:         June  1,    1981 

RE:  STATE  LONG  RANGE  INFORMATION  PROCESSING  PLAN 

The  future  direction  of  data  processing  in  Montana  state  government  is 
outlined  in  the  Long  Range  Information  Processing  Plan  which  was  issued  in 
November.    1978.     The  contents  of  this  document  establishes  many  of  the  basic 
policies  and  guidelines  which  will  be  followed  in  the  future  development  of 
data  processing  in  Montana  government.     Some  of  the  subjects  covered  are: 

Goals  and  Objectives 

Priorities  for  Computer  Processing 

Statewide  Standards 

Management  of  the  Teleprocessing  Network 

Establishment  of  the  Data  Processing  Management  Group 

Data  Base  Management 

Data  Security  and  Privacy  Issues 

Etc. 

Anyone  involved  in  the  data  processing  function  should  be  familiar  with 
the  document.     Copies  of  this  document  were  widely  distributed  when  first 
issued  and  a  limited  number  of  copies  are  still  available  from  this  office. 
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TO:  All  State  Agencies 

FROM:         Troy  W.   McGee 

Data  Processing  Coordinator 

DATE:        June  1,    1981 

RE:  EQUIPMENT  SPECIFICATIONS  AND  CONTRACTS 
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Each  agency  is  responsible  for  developing  equipment  specifications  and 
negotiating  contract  terms  with  equipment  vendors.     When  negotiating  with 
the  vendor,   it  must  be  made  clear  that  any  contract  entered  into  is  with  the 
state  of  Montana.     The  Data  Processing  Coordinator  will  be  available  for 
consultation  and  should  be  consulted  in  all  major  equipment  acquisitions. 

A  standard  state  contract  for  data  processing  equipment  has  been 
developed  and  is  available  from  this  office.     This  document  should  be  used  as 
a  guide  since  it  contains  many  terms  which  may  be  incorporated  into  a  con- 
tract.    For  example,  all  contracts  must  clearly  state  that  the  contract  will  be 
interpreted  according  to  the  Laws  of  Montana  and  venue  will  be  the  First 
Judicial  District  in  Helena,  Montana.     To  assure  that  all  legal  aspects  are 
acceptable,   the  contract  should  be  reviewed  by  legal  counsel  before  it  is 
signed. 

This  office  will  be  responsible  for  those  agreements  or  contracts  which 
are  deemed  desirable  from  an  overall  state  perspective.     For  example,   volume 
discounts,   fiscal  year  terminations,   uniform  anniversary  dates,  price  pro- 
tection, etc.  f/r'/rTt-T-,^^ 


■  *N  EOU*L  OPPOSTUNITf  euPLOYO 


d'oZd 


OFFICE  OF  THE  GOVERNOR 

BUDGET  AND  PROGRAM  PLANNING 


TED  SCHWINDEN.  GOVERNOR  CAPITOL  BUILDING 


STATE  OF  MONTANA' 
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TO:  All  State  Agencies 

FROM:        Troy  W.   McGee 

Data  Processing  Coordinator 

DATE:        June  1,   1981 

RE:  DISPOSAL  OF  DATA  PROCESSING  EQUIPMENT    '■■■ 

It  is  important  that  the  state  of  Montana  receive  the  greatest  value 
possible  when  disposing  of  data  processing  equipment.     Depending  upon  the 
status  of  the  equipment,   there  are  a  number  of  options  which  should  be 
evaluated. 

If  the  equipment  is  owned,   should  it  be: 

1.  used  as  a  trade-in? 

2.  relocated  to  another  agency? 

3.  sold  to  a  third  party? 

If  the  equipment  is  rented  or  leased,   should  it  be: 

1 .  returned  to  the  vendor? 

2.  relocated  to  another  agency? 

3.  purchased  considering  the  options  for  equipment  that  is  owned? 

To  assure  that  aU  options  are  fully  evaluated,   the  disposal  of  data 
processing  equipment  will  require  the  prior  approval  of  the  Data  Processing 
Coordinator.     When  the  disposal  of  any  data  processing  equipment  is  contem- 
plated, please  notify  this  office  as  soon  as  practical,   in  writing.     Describe 
the  equipment  in  derail,  along  with  the  financial  status  as  of  the  projected 
disposal  date.     You  will  be  be  notified  as  to  the  appropriate  disposal  selected. 
Your  vigorous  compliance  with  this  policy  can  be  financially  rewarding  to  the 
state  of  Montana. 
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TO: 

FROM: 


All  State  Agencies 

Troy  W.   McGee 

Data  Processing  Coordinator 
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DATE:        September  1,  1981 

RE:  DISPOSAL  OF  DATA  PROCESSING  PAPER 

Every  effort  should  be  made  to  aid  in  the  conservation  of  re- 
sources and  reduce  costs  to  the  state.     All  proceeds  from  the  sale  of 
data  processing  paper  for  recycling  must  accrue  to  the  benefit  of  the 
state. 

In  the  Helena  area,  the  Computer  Services  Division  of  the  Depart- 
ment of  Administration  can  make  arrangements  for  a  private  recycling 
firm  to  pick  up  the  data  processing  paper  at  your  location.     The  Com- 
puter Services  Division  will  then  appropriately  credit  your  agency's 
account.     This  will  reduce  your  administrative  efforts  and  the  need  for 
physical  transportation. 

For  further  information  regarding  this  matter,  call  the  Chief  of  the 
Operations  Bureau  at  449-2596  in  the  Computer  Services  Division. 
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APPENDIX  "D"" 


APPROVAL    CRITERIA 

FOR 

RtigUEST    FOR    PROPOSALS 

FOR 

AUTOMATIC  DATA  PROCESSING 


I  -  SYSTEMS 

II  -  EQUIPMENT 

III  -  SERVICES 


DEPARTMENT  OF  HEALTH,  EDUCATION,  AND  WELFARE 
March  31,  1980 
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APPROVAL  CRITERIA  FOR  REQUESTS  FOR  PROPOSALS 

FOR 
AUTOMATIC  DATA  PROCESSING 
SYSTEMS,  EQUIPMENT  AND  SERVICES 


Title  45  CFR  95.  611  requires  States  to  obtain  HEW  approval 
of  requests  for  proposals  (RFPs)  for  automatic  data  pro- 
cessing systems,  equipment  and  services  prior  to  State 
issuance  of  the  RFP  for  solicitation  of  proposals  from  com- 
mercial sources. 

The  RFP  provides  HEW  with  specific  information  on  a  proposed 
acquisition  and  presents  the  procedures  the  State  will  use 
in  the  procurement.   In  the  event  the  RFP  deviates  signifi- 
cantly from  the  approved  advance  plan,  the  State  needs  to 
explain  the  deviation. 

States  issue  RFPs  for  a  wide  variety  of  needs.   Conse- 
quently, these  criteria  are  stated  in  general  terms  that  are 
adaptable  to  the  different  needs  and  situations  that  the 
State  may  face. 

The  HB<7  review  will  focus  on  those  elements  of  a  RFP  that 
are  fundamental  in  obtaining  data  processing  systems  that 
will  aid  in  the  efficient  and  effective  administration  and 
management  of  HEW  programs.   The  criteria  do  not  address 
items  normally  found  in  RFP  "boiler  plate"  that  are  pri- 
marily procurement  issues.   For  those  RFP  elements.  States 
need  to  comply  with  requirements  that  are  specified  in 
Federal  procurement  rules  and  regulations  and  with  the  pro- 
curement requirements  of  the  individual  States. 
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I   APPROVAL  CRITERIA  -  REQUESTS  FOR  PROPOSALS  -  SYSTEMS 


A.   Management  of  the  Procurement  Process 

1.  Does  the  RF?  identify  the  issuing  office  and  the 
agency  (program  com?cnent(s) )  that  will  use  the 
system,  and  the  agency  manager  responsible  for  the 
system  procurement? 

2.  Does  the  RFP  include  a  procurement  schedule  that  allows 
sufficient  time  for  pre-proposal  conferences, 
preparation  of  proposals,  evaluation,  date  of  award, 
and  initiation  of  work? 

3.  Does  the  RF?  comply  with  title  A5  CFRPart  74  that 
requires  "to  the  maximum  extent  practicable,  open 
and  free  competition?" 

4.  Does  the  RF?  specify  the  format  and  organization 
for  the  proposals  and  provide  submittal  instruc- 
tions, such  as: 

(a)  time  and  date  by  which  offerors  must  submit 
proposals,  ,     . 

(b)  office  to  which  offerors  must  submit  proposals, 
and 

(c)  number  of  proposal  copies  offerors  must  submit? 

5.  Does  the  RF?  require  that  the  proposal  give  a 
statement,  including  personnel  background  and  ex- 
perience information,  of  the  contractor's  personnel 
resources  planned  for  assignment  to  the  project? 

6.  Does  the  RFP  require  a  statement  of  corporate 
financial  resources,  a  performance  bond  and  a 
history  of  prior  involvement  in  similar  projects? 

7.  Does  the  RFP  specify  that  the  prime  contractor 
selected  through  this  procurement  is  responsible  for 
contract  performance,  whether  or  not  sub-contractors 
are  used? 

8.  Does  the  RF?  specify  standards  for  sub-contractors 
as  well  as  prime  contractors  even  though  final 
responsibility  is  with  the  prime  contractor? 

9.  Does  the  RF?  state  contract  termination  provisions? 
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10.  Does  the  RFP  include  a  provision  for  penalty  in  the 
event  the  contractor  fails  to  deliver  satisfactorily 
any  of  the  products  required  in  the  RFP? 

11.  Does  the  RFP  stipulate  that  the  resulting  contract 
will  include  provision  for  State  retention  of  all 
ownership  rights  to  the  software  and  associated 
documentation  developed  or  installed  with  Federal 
financial  participation? 

12.  Does  the  RFP  state  that  the  resulting  contract  will 
include  provisions  to  allow  HEW  access  to  the 
software  and  all  related  documentation  and  records 
during  the  system  design,  development  and  operation, 
and  to  pertinent  cost  records  of  contractors  and  sub- 
contractors at  such  intervals  as  HE^^J  deems  necessary? 

13.  Does  the  RFP  specify  the  type  of  contract  that  is 
anticipated;  e.g.,  fixed  price,  cost  reimbursement, 
etc.? 

B.   Nature  and  Scope  i 

1.  Does  the  RFP: 

(a)  present  the  purpose  and  scope  of  the  proposed 
system, 

(b)  provide  background  information  on  the  proposed 
procurement,  and 

(c)  explain  relationship(s )  of  the  proposed  system 
with  other  system(s)  and  organizations? 

2.  Does  the  RFP  reference  or  include  previously  prepared 
documentation  that  will  help  potential  offerors  under- 
stand the  proposed  project  and  aid  in  their  proposal 
preparation? 

3.  Does  the  RFP  describe  the  existing  methods  and 
procedures  that  the  proposed  system  will  supple- 
ment, change  or  replace? 

4.  Does  the  RFP  contain  information  on: 

(a)  organizational  responsibilities, 

(b)  equipment  available  and  required, 

(c)  software  available  and  required, 

(d)  volume  and  frequency  of  inputs  and  outputs, 
and 

(e)  constraints  and  limitations  in  terms  of  program 
requirements,  organization  and  costs? 
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5-.   Does  the  RFP  illustrate  the  proposed  data  flow 
^  and  management  to  present  an  overall  view  of  the 

planned  capabilities? 

6.  Does  the  RFP  state  the  major  objectives  of  the  pro- 
posed system;  e.g. : 

(a)  new  or  improved  service  delivery, 

(b)  operational  efficiency, 

(c)  enhanced  programmatic  or  administrative  controls? 

7.  Does  the  RFP  itemize  improvements  with  associated 
time  frames  the  agency  will  obtain  by  the  proposed 
system,'  such  as: 

(a)  new  capabilities, 

(b)  upgraded  existing  capabilities, 

(c)  elimination  of  existing  deficiencies,  and 

(d)  improved  timeliness,  e.g.,  decreased  response 
time  or  processing  time? 

8.  Does  the  RFP  contain  an  explanation  of  project 
phasing,  if  phasing  is  contemplated? 

C.   Functional  Requirements 

1.  Does  the  RFP  state  the  functions  required  in  the 
proposed  system  in  quantitative  and  qualitative 
terms,  and  how  those  functions  will  satisfy  the 
programmatic  and/or  administrative  requirements? 

2.  Does  the  RFP  state  performance  requirements  of  e.g. : 

(a)  data  accuracy  standards  -  mathematical, 
logical,  transmission, 

(b)  data  validation, 

(c)  timing  -  response  time,  processing  time,  and 

(d)  flexibility  in  design  to  provide  capability  in 
operating  environment,  interfaces  with  other 
software,  organizational  impact,  with  respect  to 
future  changes  or  improvements? 

3.  Does  the  RFP  specify  security  and  privacy  require- 
ments of  the  proposed  system? 

4.  Does  the  RFP  specify  inclusion  in  the  proposed 
system  of  safeguards  against  fraud,  abuse  and 
waste? 
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5   Does  the  RF?  reauire  a  proposed  problem  solution 

that  uses  proven  technology  as  opposed  to  experimen- 
tal technology  that  may  or  may  not  be  successrul? 

6.   Does  the  RFP  require  estimates  of  the  level  of 
effort  anticipated,  expressed  in  person-years  or 
other  reasonable  indicators? 

).   Deliverables 

1.  Does  the  RFP  specify  the  products  the  State  expects 
the  contractor  to  deliver? 

2.  Does  the  RFP  state  the  review  and  approval  period 
for  each  deliverable? 

3  Does  the  RFP  identify  the  documentation  and  opera- 
tion standards  the  contractor  is  expected  to  use? 

4  Does  the  RFP  specify  requirements  for  user  training, 
conversion,  system  implementation  and  acceptance 
when  applicable? 

5.  Does  the  RFP  stipulate  responsibility  of  the 
contractor  for  contract  deliverables? 

6.  Does  the  RFP  require  a  schedule  of  proposed  work 
with  defined  milestones  for  contract  deliverables? 

E.   Management  Plan 

1   Does  the  RFP  state  the  functional  title  of  the  State 
project  manager  to  whom  the  contractor  will  report? 

2.  Does  the  RFP  specify  type  and  frequency  of  project 
status  reports? 

3.  Does  the  RFP  describe  the  plan  for  State  review  and 
approval  of  work  performed  during  the  lifetime  o£ 
the  project? 

4    Does  the  RFP  define  the  billing  method  the  contrac- 
tor will  use  to  ensure  identification  of  costs  for 
each  Social  Security  Act  program? 

F.   Proposal  Evaluation 

1.   Does  the  RFP  describe  the  method  the  State  will  use 
in  evaluating  proposals? 


i>-6 


-5- 

J  ■ 

2.   Does  the  RFP  specify  evaluation  criteria  that 

emphasize  primary  considerations  that  will  lead  to 
successful  accomplishment  of  the  proposed  project? 
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II   APPHOVrtL  C?.ITERIn  -  REQUESTS  FOR  PROPOSALS  -  EQUIPMENT 

A.  Manacer.ent  of  the  Procurexent  Process 

1.  Does  ths  RF?  identify  the  issuing  office,  the  agency 
(progra."n  corapcnent(  s)  )  that  will  use  the  equipment, 
and  the  agency  point  of  contact  for  the  equipment 
procurement? 

2.  Does  the  RF?  include  a  procurement  schedule  that 
allows  sufficient  time  for  pre-prcposal  conferences, 
preparation  of  proposals,  benchmarking,  evaluation, 
date  of  award  and  installation  of  the  equipment 
being  acquired? 

3.  Does  the  RFP  comply  with  title  45  CFR  Part  74  that 
requires  "to  the  maximum  extent  practicable,  open 
and  free  competition?" 

4.  Does  the  RF?  specify  the  format  and  organization  for 
the  proposals  and  provide  submittal  instructions, 
such  as: 

(a)  time  and  date  by  which  offerors  must  submit 
proposals,       ^ 

(b)  office  to  which  offerors  must  submit  proposals, 
and 

(c)  number  of  proposal  copies  offerors  must  submit? 

5.  Does  the  RFP  require  a  statement  of  corporate  finan- 
cial resources,  a  performance  bond  and  a  histoy 

of  prior  involvement  in  similar  projects? 

6.  Does  the  RFP  state  contract  termination  provisions? 

7.  Does  the  RFP  include  a  provision  for  penalty  in  the 
event  the  contractor  fails  to  deliver  satisfactorily 
any  of  the  products  required  in  the  RFP? 

8.  Does  the  RFP  identify  the  preferred  method  of 
payment,  such  as  rental,  lease  or  purchase? 

B.  Nature  and  Scooe 

- 

1.   Does  the  RFP: 

(a)   present  the  purpose  and  scope  of  the  proposed 
#!^.  equipment  acquisition,  and 
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(b)   provide  background  informatioa  on  the  proposed 
acquisition? 

->        noPs  th-  RF^  reference  or  include  previously  prepared 
'•   a°ocLen;a?lin%hat  will  help  ^^^^^^^^^^'^ 
the  proposed  acquisition  and  aia  in  thei.  proposa- 

preparation? 

-K        roes  the  RF?  describe  existing  ir.ethods  and  proce- 
dSrSs  that  the  proposed  equipment  will  support, 
change  or  replace? 

4.   Does  the  RFP: 

(a)  itemize  existing  equipment, 

(b)  describe  the  existing  equipment  that  the  new 
equipment  will  replace, 

(c)  explain  relationshipCs)  of  the  P^°P°=^"3,^2^'^" 
ment  with  other  existing  or  planned  systems  and 
equipment  configuration,  and 

(d)-  describe  the  proposed  integration  of  new  equip- 
ment  with  currently  installed  equipment  the 
State  will  retain? 

Does  the  RFP  itemize  existing  operating  systera(s), 
data  base  manager  and  other  software? 
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C.   Mandatory  Functional  Requirements 

1   Does  the  RFP  describe  the  requirements  of  the  equip- 
*  ment  being  acquired  for  factors  such  as: 

(a)  thruput  requirement, 

(b)  storage  capacities, 

(c)  transaction  and  I/O  volumes 

tA\      teleorocessing  transmission  rates, 
e  ••  ditio?  processing  sequencing  requirements,  or 
(f)   timing  or  turnaround  restrictions? 

•5   nopc;  the  RFP  soecify  equipment  performance  require- 
men?s  for  those  factors  that  workload  specifications 
inadequately  describe;  and,  if  so,  do  the  require- 
ments fall  within  a  range  to  allow  maximum 
competition? 

3.   Does  the  RF?  specify  operational  use  time  in  terms         r 
of: 

(a)  equipment  availability,  and 

(b)  minimum  downtime? 
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4.-  Does  the  RF?  state  technical  requirements  for 
features  to  accomnodate  security  requirements? 

5.  Does  the  RF?  state  requirements  for: 

(a)  provision  of  operating  software, 

(b)  performance  of  operating  software,  and 

(c)  implementation  of  operating  software  modifica- 
tions and  revisions? 

6.  Does  the  RFP  specify  data  base  management 
requirements? 

D.  Mandatory  Suooort  Reauirements 

1.  Does  the  RFP  specify  maintenance  requirements  for: 

(a)  on-site  maintenance, 

(b)  on-call  maintenance,  and 

(c)  availability  of  replacement  parts? 

2.  Does  the  RFP  require  on-site  field  modification  of 
equipment  on  at  least  the  same  basis  as  furnished  to 
other  customers?      , 

3.  Does  the  RFP  describe  required  contractor  support 
.  for: 

(a)  staff  training,  and 

(b)  manuals  and  publications?  -  ■ 

4.  Does  the  RF?  state  conditions  and  responsibility  for 
equipment  transportation,  packing,  unpacking  and 
movement? 

5.  Does  the  RFP  describe  existing  or  planned  facili- 
ties, e.g.  : 

(a)  available  power, 

(b)  available  air  conditioning,  chilled  water, 

(c)  floor  area,  and 

(d)  access  doors? 

E.  Desirable  Features 

Does  the  RF?  specify  desirable  features? 
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F.  Conversion  Considerations  ''— ' 

1,  'Does  the  RFP  describe  the  requirements  for  data  file 

and  application  software  conversion  or  reprogramming? 

2.  Does  the  RFP  specify  conditions  for  conversion  or 
reprogramming  of  data  files  and  application  software 
in  terms  of: 

(a)  responsible  party, 

(b)  cost,  and 

(c)  schedule? 

G.  Cost  Alternatives 

1.   Does  the  RFP  clearly  state  the  minimum  period  for 
which  the  equipment  is  to  be  used,  and  request  the 
offerors  to  submit  a  cost  proposal  that 

(a)  covers  the  minimum  period, 

(b)  allows  for  alternate  pricing  for  longer 
periods, 

.(c)   allows  for  different  acquisition  and  pricing 

structures  such  as  purchase,  lease,  lease-  ^ 

purchase  with  purchase  credits? 

H.   Acceptance  Testing 

Does  the  RFP  describe  acceptance  testing  procedures  and 
time  frames? 

I.   Proposal  Evaluation 

1.  Does  the  RFP  describe  the  method  the  State  will  use 
in  evaluating  proposals? 

2.  Does  the  RFP  specify  evaluation  criteria  that  emphasize 
mandatory  requirements  of  the  proposed  equipment? 

3.  Does  the  RFP  specify  evaluation  factors  associated 
with  desirable  features? 
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III   A??ROV?.L  C^^ITERIA  -  REQUESTS  ?CR  ?RC?OS;MS  -  SE'RVZCIS 


A.   Manacerr.ent  of  the  ?rscurer.ent  Process 

1.  Does  the  RF?  identify  the  issuing  office,  the  agency 
(program  component(s')  )  that  will  use  the  service, 

and  the  agency  point  of  contact  for  the  service 
procurement? 

2.  Does  the  RFP  include  a  procurement  schedule  that 
allows  sufficient  time  for  cre-orcposal  conferences, 
preoaration  of  proposals,  evaluation,  date  of  award, 
and  initiation  of  the  service  being  acquired? 

3.  Does  the  RF?  comply  with  title  45  CFR  Fart  74  that 
requires  "to  the  maximum  extent  practicable,  open 
and  free  competition?" 

4.  Does  the  RFP  specify  the  format  and  organization  for 
the  proposals  and  provide  submittal  .instructions; 
such  as: 

(a)  time  and  date  by  which  offerors  must  submit 
proposals, 

(b)  office  to  which  offerors  must  submit  proposals, 
and 

(c)  number  of  proposal  copies  offerors  must  submit? 

5.  Does  the  RFP  require  that  the  proposal  give  a  state- 
ment, including  personnel  background  and  experience 
information,  of  the  contractor's  personnel  resources 
planned  for  assignment  to  the  project? 

6.  Does  the  RFP  require  a  statement  of  corporate  finan- 
cial resources  and/or  a  performance  bond  and  a 
history  of  prior  involvement  in  similar  projects? 

7.  Does  the  RFP  specify  that  the  prime  contractor 
selected  through  this  procurement  is  responsible  for 
contract  performance,  whether  or  not  sub-contractors 
are  used? 

8.  Does  the  RFP  specify  standards  for  sub-contractors 
as  well  as  prime  contractors,  even  though  final 
responsibility  is  '^ith  the  prime  contractor? 

9.  Does  the  RFP  state,  contract  termination  provisions? 
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10.  Does  the  R??  include  a  prevision  for  penalty  in  the 
event  the  contractor  fails  to  deliver  the  specified 
service  satisfactorily? 

11.  Does  the  R??  state  that  the  resulting  contract  will 
include  orovisions  to  allow  KEW  access  to  the  software 
and  all  related  docunientation  and  records  curing  the 
service  operation,  and  to  cost  records  of  contractors 
and  sub-contractors  at  such  intervals  as  HE77  deems 
necessary? 

12.  Does  the  RFP  specifv  the  type  of  contract  that  is 
anticipated;  e.g.,  fixed  price,  cost  reimbursement, 
etc.? 

B.   Nature  and  Scope 

1.   Does  the  RFP: 

(a)  present  the  purpose  and  scope  of  the  proposed 
service, 

(b)  provide  background  information  on  the  proposed 
procurement,  and 

(c)  explain  relationshi?(s)  of  the  proposed  service 
to  the  agency's  functions  and  system(s)? 

2   Does  the  RFP  reference  or  include  previously  prepared 
documentation  that  will  help  potential  offerors  under- 
the  proposed  service  and  aid  in  their  proposal 
preparation? 

3.   Does  the  RFP  contain  information  on: 

(a)  organizational  and  personnel  responsibilities, 

(b)  equipment  available  and  required,  and 

(c)  constraints  and  limitations  in  terms  of  program 
requirements,  organization  and  costs? 

C.   Functional  Requirements 

1.  Does  the  RFP  state  the  functions  of  the  proposed 
service  in  quantitative  and  qualitative  terms,  and 
how  those  functions  will  satisfy  the  programmatic 
and/or  administrative  requirements? 

2.  Does  the  RFP  require  expansion  of  the  service,  if  the 
workload  exceeds  the  initial  resource  requirements 
specified  in  the  RFP? 
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3.  Does  the  RFP  specify  the  period  of  service 
availability? 

4.  Does  the  RF?  state  the  location  of  the  service  or  of 
product  delivery? 

5.  Does  the  RFP  state  workload  requirements  in  terrfis  of 
regular  and  peakload  volume  and  processing  schedule? 

6.  Does  the  RFP  state  performance  requirements  in  terms 
such  as: 

(a)  data  accuracy  standards  -  mathematical, 
logical,  transmission, 

(b)  data  validation,  and 

(c)  timing  -  response  time,  processing  time? 

7.  Does  the  RFP  specify  requirements  for  interfaces 
with  operating  environment  (e.g.,  equipment, 
communication  network,  software  and  other  systems)? 

8.  -Does  the  RFP  specify  security  and  privacy  require- 
ments of  the  proposed  service? 

9.  Does  the  RFP  specify  requirements  for  safeguards 
against  fraud,  abuse  and  waste? 

10.  Does  the  RFP  describe  user  training  requirements  in 
terms  of  skills,  number  of  trainees  and  location  of 
training? 

11.  Does  the  RFP  specify  needed  documentation  in  terms 
of  user  manuals,  operating  instructions,  design 
descriptions  and  standards,  and  specify  an 
appropriate  number  of  copies? 

12.  Does  the  RFP  describe  the  resources  the  State  will 
make  available  to  the  contractor? 

D.   Management  Plan 

1.  Does  the  RFP  state  the  functional  title  of  the  State 
project  manager  to  whom  the  contractor  will. report? 

2.  Does  the  RFP  require  a  schedule  of  proposed  work 
with  dates  or  time  frames  for  service  deliverables? 
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3. 


nop^  -he  RF^   describe  the  olan  for  State  review  and 

Does  une  at-  uco« "^^      .    _    ^.u^  ii<=c.'-im(a  nf 

aooroval  of  work  performed  during  the  lifetime  ot 


r'^ 
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the  project? 


4.   Does  the  RF?  specify  type  and  frequency  of  project 
status  reports? 

'=,  Does  the  RFP  define  the  billing  method  the  contrac- 
?or  will  use  to  ensure  indentif ication  of  costs  for 
each  Social  Security  Act  program? 

Proposal  Evaluation 

1.  Does  the  RFP  describe  the  method  the  State  will  use 
in  evaluating  proposals? 

2.  Does  the  RFP  specify  evaluation  criteria  that  emphasize 
primary  considerations  of  the  proposed  service. 
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APPROVAL  CRITERIA  FOR  SYSTEMS  SPECIFICATIONS 

FOR 

AUTOMATIC  DATA  PROCESSING  SYSTEMS 


Title  45  CFR  95.611  provides  for  States  to  obtain  prior  approval 
for  system  design  and  system  specifications  as  required  by  HEW. 
The  Department  will  notify  the  State  agency  if  such  prior 
approval  is  required.   The  action  will  occur  for  selected  systems. 
Types  of  development  efforts  HEW  may  select  for  review  include, 
but  are  not  limited  to: 

-  systems  progressing  from  plans  that  provide  for 
determination  of  the  kind  of  system  the  State  will 
develop  in  first  phase  activities  such  as  feasibility 
studies  or  system  studies 

-  planned  systems  with  unique  approaches  to  problem 
solutions 

complex  systems. 

HEW's  review  process  calls  for  approval  of  advance  plans  prior 
to  States'  initiation  of  action  to  obtain  a  system.   At  that 
early  time,  States  will  not  always  have  the  information  HEW  needs 
to  aporove  a  system  in  its  entirety.   This  is  true  particularly 
in  those  instances  where  advance  plans  include  provisions  for 
exploring  alternative  approaches  to  the  problem  solution  and 
determining  system  type  as  a  first  phase  activity.   When  the 
State  uses  contractor  support  for  system  development  and  imple- 
mentation, HEW  is  provided  more  definitive  information  through 
review  of  the  request  for  proposal.   However,  when  States  develop 
systems  with  in-house  staff,  they  do  not  routinely  submit  the 
more  definitive  information  generated  subsequent  to  advance  plan 
preparation.   The  material  available  in  States  when  system  specifi- 
cations are  completed . will  provide  HEW  with  the  level  of  detail 
needed  for  assessment  of  the  viability  of  the  State's  approach 
to  problem  solution.   HEW  considers  that  point  a  critical  one 
for  system  review. 

The  system  specification  approval  criteria  delineate  the  type  of 
information  HEW  will  expect  States  to  furnish  for  selected 
reviews.   In  preparing  these  criteria,  HEW  is  not  attempting  to 
pre-judge  the  appropriate  form  for  State  system  specifications; 
the  criteria  are  intended  to  give  States  a  sense  of  the  tests 
HEW  applies  to  system  specifications  in  funding  decisions.   If 
some  of  the  specified  information  was  included  in  the  advance 
planning  document,  States  need  not  resubmit  it.   In  the  event 
the  system  specifications  deviate  significantly  from  the  approved 
advance  plans,  States  need  to  explain  the  deviation.  i 
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APPROVAL  CRITERIA  -  SYSTEM  SPEC IFICATIOMS 

A.   Background 

1.  DO  the  system  specifications  present  a  general  over- 
view that: 

(a)  specifies  the  program  and  administrative 
requirements.,  and 

(b)  describes  the  proposed  system? 

2.  Do  the  system  specifications: 

(a)  identify  the  project  sponsor,  developer,  user 
and  the  computer  center  or  network  where  soft- 
ware will  be  implemented, 

(b)  list  the  applicable  references  such  as: 

(1)  project  authorization; 

(2)  previously  published  documents  on  the 
project;  and 

•(3)   documentation  concerning  related  projects; 

(c)  state  the  estimated  begin  date  and  the  period 
of  time  the  system  will  operate;  and 

(d)  provide  pertinent  cost  considerations 
(developmental  and  operational)? 

B.   Functional  Requirement  Specifications 

1  DO  the  specifications  describe  in  detail  the  functions 
that  the  system  must  perform  in  order  to  meet  user  needs? 

2  DO  the  specifications  explain  how  the  proposed  system 
'   will  contribute  to  the  attainment  of  programmatic  or 

administrative  objectives,  e.g.: 

(a)   what  difference  will  the  system  make  in  service 
delivery  in  terms  of  quantity,  quality,  time  and 
cost? 
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(b)  what  ooeraticnal  iinprovements  will  the  system 
attain, 

(c)  how  will  programmatic  or  administrative 
accountability  be  established  or  improved,  and 

(d)  what  performance  standards  will  measure  objec- 
tive attainment? 

3.  Co  the  specifications  propose  a  system  designed 
around  existing  functional  organizations  and 
existing  procedures?   If  not,  does  the  schedule  pro- 
vide for  phasing  in  a  new  organizational  or  proce- 
dural structure  in  a  time  frame  consistent  with  the 
development  of  the  proposed  system? 

4.  Do  the  specifications  identify  techniques  and  proce- 
dures from  other  systems  that  will  be  used  or  that 
will  become  part  of  the  proposed  system?  Do  the 
specifications  propose  phasing  out  functions  in 
other  systems  that  are  proposed  in  the  new  system? 

5.  Do  the  specifications  propose  an  approach  that  pro- 
ceeds from  a  base  in  a  modular  framework;  that  is, 
develop,  test  and  implement  segments  of  the  overall 
system  before  proceeding  to  other  segments  or  will 
the  entire  system  be  brought  into  operation  at  one 
time?  Do  the  specifications  provide  rationale  for 
the  proposed  approach? 

6.  Do  the  specifications  propose  proven  technology  as 
opposed  to  experimental  technology? 

C.   Design  Specifications 

1.  Do  the  specifications  identify  the  data  inputs, 
e.g. : 

(a)  describe  the  major  data  elements  by  name,  their 
coded  representations,  relevant  dictionaries, 
tables  and  reference  files;  and 

(b)  specify  the  data  medium  (disk,  magnetic  tape, 
etc. )  and  data  format? 

2.  Do  the  specifications  define  the  major  processing 
requirements,  e.g.: 

(a)   state  the  functions  required  of  the  processing 
segments  in  quantitative  and  qualitative  terms; 
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(b)      specify  performance   rr.easures    for: 

M)      progranmatic   standards, 

^:        ^«;ni  =^rativ«    functions,    anc 

(2)  adminis  wra>-iv  - 

(3)  ooerational  processes, 
,e,   specifi .operational  performance  measures  in 


terms  oi: 


(1)  data  accuracy       ^omoarability 

(2)  data  ^^^^f^l^ll/^lls   conditions  for: 
.  (3)   timing  under  various 

-  response  time  _ 

:     ttTl.Tatnn:i  't;rns.ission  time 

-  throughput  time 

(1,  changes  in  modes  °£  °P«^'^°"' 

•  4     Ttrrfacls^wltroth^r' software,         . 
(3)   interfaces  wiuu    ,-T,nT-ovements ,  and 

U)  ?^-"^\=^tsrati-  anHegulatoiy  changes? 
(5)   future  legisiacive 

,   oo  the  soecifications  describe  the  data  flow  between 
'•  ^^ocessing  segments  in  terms  of: 

(a)  data  elements 

(b)  format 
(ci   control 

,.  .0  the  specifications  identify  the  data  outputs  in 
terms  of: 

(a)  content 

(b)  format 

(c)  frequency _  "  . 

(d)  distribution 

5.   no  the  specifications  describe  the  operating 
environment  in  terms  of: 
(a)   equipment  -  e.g. » 

(1)  physical  and  geographic  distribution  of 
o,  'ctpfcfty'of  processor  and  internal  storage, 
3   data  storage  aevices,  and 
(4)  data  transmission  devices 
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6. 


7. 


(a) 
(b) 
(c) 
(d) 


^,b)   softvare,  e.g.  , 

(1)  ccerating  systen\, 

(2)  data  base  manager, 

C^)      ot'ner  suocort  software, 

(4  J   application  programing  language 

CO  the  specifications  delineate  privacy  security^ 
and  recovery  standards  ana  procecu-.s 

safeauards   to   prevent   orograironatic   and   adir^in- 

istrative  fraud,  abuse,  and  was.e, 

specifications  for  internal  system  audits  and 

controls, 

specifications  for  State/Federal  audit  func- 

tions,  and 

security  and  privacy  ^^ril^^^T^AT^V-'^   °'' 
the  software  (45  CFR  205.50  and  302.18). 

■c-      ^n-^nc  ^hate  the  Dossible  failures  of 

^^   jrul^r-e  P^Srefsin^  ^^^itre.en.s  s.c.  as: 

«  n,       o-roressina  redundancy 

for  regular  data  files, 

1      «  /-   hhp  use  of  another 
'^'  i'yllTf.   f.Sr/™:;'n;'.o'tcro.pUs.  .one  por- 
tion  of  the  requirements, 

rr^   recovery  and  restart,  e.g.,  the  check  points  in 
^^^      the  system  where  software  execution  can  be 

resumed,  and 
(d)  operational  controls,  including  sources  of 

these  controls? 
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D.   System  Dccumentation 

1.  DO  the  specifications  explain  cocuruentation  require- 
ments  and  standards  for: 

(a)  software  documentation, 

(b)  operational  instructions,  ana 

(c)  user  manuals? 

2.  DO  the  specifications  describe  user  training  aids  and 
documentation  requirements? 

3.  DO  the  specifications  outline  a  plan  to  convert  from  the 
current  to  the  new  system? 

E.   Management  Plan 

1.   DO  the  specifications  include  a  project  management 
plan  that: 

(a)   states  the  functional  title  of  the  project 
manager, 

.(b)   specifies  the  typfe  and  frequency  of  project 
status  reports,  and 

(c)   describes  the  plan  for  review  and  JPP^o^al  of 
^    wo?k  performed  during  the  period  of  system 
development  and  implementation? 

2       DO  the  specifications  describe  resource  requirements 
for  the  System  detail  specifications,  development, 
implementation  and  operation  in  terms  of: 

(a)  staff  numbers  and  skills,  and 

(b)  equipment  capability  for  the  different  phases 
of  the  project? 

3.   Do  the  specifications: 

l^\      identify  projected  cost  for  systems  development 
^    ^      and  operation  including  direct  and  indirect 
cost,  and 

(b)   define  the  cost  identification  method  the  State 
will  use  to  determine  costs  attributable  to 
each  Social  Security  Act  program? 
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(10  That  a  complainant  prevailing  in 
a  civil  action  has  the  right  to  be 
awarded  the  costs  of  the  action,  in- 
cluding reasonable  attorney's  fees,  but 
that  these  costs  must  be  demanded  in 
the  complaint: 

(iii)  That  before  commencing  the 
action  the  complainant  shall  give  30 
days  notice  by  registered  mail  to  the 
Secretary,  the  Attorney  General  of 
the  United  States,  the  head  of  the 
granting  agency,  and  the  recipient; 

(iv)  That  the  notice  shall  state:  the 
alleged  violation  of  the  Act:  the  relief 
requested:  the  court  in  which  the 
action  will  be  brought:  and  w-hether  or 
not  attorney's  fees  are  demanded  in 
the  event  the  complainant  prevails; 
and 

(V)  That  no  action  shall  be  brought 
if  the  same  alleged  violation  of  the  Act 
by  the  same  recipient  is  the  subject  of 
a  pending  action  in  any  court  of  the 
United  States. 

Subpart  E — Future  Review  of  Age 
Discrimination  Regulations 

§  90.61     Review  of  general  regulations. 

The  Secretary  shall  review  the  effec- 
tiveness of  these  regulations  in  secur- 
ing compliance  with  the  Act.  As  part 
of  this  review,  30  months  after  the  ef- 
fective date  of  these  regulations,  the 
Secretary  shall  publish  a  notice  of  op- 
portunity for  public  comment  on  the 
effectiveness  of  the  regulations.  The 
Secretary  will  assess  the  comments 
and  publish  the  results  of  the  review 
and  assessment  in  the  Federal  Regis- 
ter. 

§  90.62    Review  of  agency  regulations. 

Each  agency  shall  review  the  effec- 
tiveness of  its  regulations  in  securing 
compliance  with  the  Act.  As  part  of 
this  review,  30  months  after  the  effec- 
tive date  of  its  regulations,  each 
agency  shall  publish  a  notice  of  oppor- 
tunity for  public  comment  on  the  ef- 
fectiveness of  the  agency  regulations. 
Each  agency  shall  assess  the  com- 
ments and  publish  the  results  of  the 
review  in  the  Federal  Register. 
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TION—GRANT PROGRAMS 
(PUBLIC  ASSISTANCE  AND  MEDI- 
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Subpart  F — AutomaHc  Data  Procctiing  Equl|>- 
mant  and  Strvlcti — Condilieni  for  Fadaral 
Financing  Participolion 

General 

Sec. 

95  601    Scope  and  applicability. 

95. 60S    Definitions. 

Spccinc  Conditions  for  FFP 

95.611  Prior  approval  conditions. 

95.612  Prior  notice  conditions. 

95.613  Procurement  standards. 
95.615  Access  to  records. 

95.617    Software  owTierstnlp  rights. 
95  619    Ubc  of  ADP  systems. 
95.621     ADP  reviews. 

95.623    Wailver  of   prior   approval   require- 
ments. 

Cost  Allocation  Plan 

95.631    Relationship  to  the  approved  cost 

allocation  plan. 
95.633    Nondiscrimination  requirements. 

Exemptions 

95.641     Exemption  from  45  CFR  205.160(a) 

and  304.24. 
95.643    Exemption   from   45   CFR  Part  74, 

Appendix  C.  Part  II  C.l. 

Authority:  Sec.  1102.  49  Stat.  647.  42 
U.S.C.  1302:  sec.  7(b)  68  Stat.  658.  29  U  S.C. 
37(b):  sec.  139.  84  Stat.  1323,  42  U.S.C. 
2577b;  sec.  144,  81  Stat.  529,  42  U.S.C.  2678. 


Source:    43    FR    44853. 
unless  otherwise  noted. 


Sept.    29.     1978, 


Subpart  A — E     [Reserved] 

Subpart  F — Automatic  Data  Process- 
ing Equipment  and  Services — Con- 
ditions for  Federal  Financial  Partici- 
pation 

General 

§  95.601     Scope  and  applicability. 

This  subpart  prescribes  the  condi- 
tions under  which  the  Department  of 
Health  and  Human  Services  will  ap- 
prove Federal  financial  participation 
(FFP),  at  the  applicable  rates,  for  the 
costs  of  automatic  data  processing  In- 
curred under  an  approved  State  plan 
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for  titles  I.  IV-A,  IV-B.  IV-C.  IV-D,  X 
XIV,  XVI  (AABD),  XIX,  or  XX  of  the 
Social  Security  Act. 

§95.605    Derinitions. 

"Acceptance  documents"  means 
written  evidence  of  satisfactory  com- 
pletion of  an  approved  phase  of  work 
or  contract,  and  acceptance  thereof  by 
the  State  agency. 

"Acquisition"  means  acquiring  ADP 
equipment  or  services  from  commer- 
cial sources  or  from  State  or  local  gov- 
ernment resources. 

"Advance  planning  document"  or 
"APD"  means  a  written  plan  of  action 
to  acquire  the  proposed  ADP  services 
or  equipment.  The  APD  must  contain 
a  statement  of  needs  and  objectives;  a 
preliminary  cost/benefits  analysis;  a 
personnel  resource  statement  indicat- 
ing availability  of  qualified  and  ade- 
quate staff,  including  a  project  direc- 
tor to  accomplish  the  project  objec- 
tives; a  detailed  description  of  the 
nature  and  scope  of  the  activities  to  be 
undertaken  and  the  methods  to  be 
used  to  accomplish  the  project;  a  pro- 
posed activity  schedule  for  the  project; 
a  proposed  budget;  and  a  statement  in- 
dicating the  period  of  time  the  State 
expects  to  use  the  ADP  service  or 
equipment. 

"Approving  component"  means  an 
organization  within  the  Department 
that  is  authorized  to  approve  requests 
for  the  acquisition  of  ADP  equipment 
or  ADP  services;  Social  Security  Ad- 
ministration (SSA)  for  cash  assistance 
for  titles  I,  IV-A,  X,  XIV,  and  XVI 
(AABD):  Office  of  Human  Develop- 
ment services  (OHDS)  for  social  serv- 
ices for  titles  I,  IV-A,  IV-B.  IV-C,  X, 
XIV,  XVI  (AABD).  and  XX;  Office  of 
Child  Support  Enforcement  (OCSE) 
for  title  IV-D;  and  Health  Care  Fi- 
nancing Administration  (HCFA)  for 
title  XIX  of  the  Social  Security  Act. 

"Automatic  data  processing"  or 
"ADP"  means  data  processing  per- 
formed by  a  system  of  electronic  or 
electrical  machines  so  interconnected 
and  interacting  as  to  minimize  the 
need  for  human  assistance  or  interven- 
tion. 

"Automatic  data  processing  equip- 
ment" or  "ADP  equipment"  means: 

(a)  Electronic  digital  computers,  re- 
gardless of  size,  capacity,  or  price,  that 
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accept  data  input,  store  data,  perfol 
calculations,     and     other     processing 
steps  and  prepare  information  output; 

(b)  All  peripheral  or  auxiliary  equip- 
ment used  in  support  of  electronic 
computers  whether  selected  and  ac- 
quired with  the  computer  or  separate- 
ly: 

(c)  Data  transmission  or  communica- 
tions equipment  that  is  selected  and 
acquired  solely  or  primarily  for  use 
with  a  configuration  of  ADP  equip- 
ment which  includes  an  electronic 
computer;  and 

(d)  Data  input  equipment  that  is 
used  to  enter  data  directly  or  indirect- 
ly into  an  electronic  digital  computer; 
peripheral  or  auxiliary  equipment;  or 
data  transmission  or  communications 
equipment. 

"Automatic  data  processing  services" 
or  "ADP  services"  means: 

(a)  Services  to  operate  ADP  equip- 
ment, either  by  private  sources,  or  by 
employees  of  the  State  agency,  or  by 
State  or  local  organizations  other  than 
the  State  agency;  and/or 

(b)  Services  provided  by  private 
sources  or  by  employees  of  the  State 
agency  or  by  State  and  local  organiza- 
tions other  than  the  State  agency  to 
perform  such  tasks  as  feasibility  stud- 
ies, system  studies,  system  design  ef^^ 
forts,  development  of  system  specifics 
tions.  system  analysis,  programing  and 
system  implementation. 

"Data  processing"  means  the  prepa- 
ration of  source  media  containing  data 
or  basic  elements  of  information,  and 
the  use  of  such  source  media  accord- 
ing to  precise  rules  of  procedures  to 
accomplish  such  operations  as  classify- 
ing, sorting,  calculating,  summarizing, 
recording,  and  transmitting. 

"Department"  means  the  Depart- 
ment of  Health  and  Human  Services. 

"Feasibility  study"  mean.s  a  prelimi- 
nary study  to  determine  whether  it  is 
sufficiently  probable  that  effective 
and  efficient  use  of  ADP  equipment  or 
systems  can  be  made  to  warrant  the 
substantial  Investment  of  staff,  time, 
and  money. 

"FFP"  means  Federal  financial  par- 
ticipation. 

"Service  agreement"  means  a  docu- 
ment signed  by  the  State  or  local 
agency  and  the  State  or  local  central 
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data  processing  facility  providing  ADP 
services  (provider)  which: 

(a)  Identifies  those  ADP  services  the 
central  data  processing  facility  will 
provide; 

(b)  Includes,  preferably  as  an  amen- 
dable attachment,  a  schedule  of 
charges  for  each  identified  ADP  serv- 
ice, and  a  certification  that  these 
charges  apply  equally  to  all  users; 

(c)  Includes  a  description  of  the 
method(s)  of  accounting  for  the  serv- 
ices rendered  under  the  agreement 
and  computing  services  charges; 

(d)  Includes  assurances  that  services 
provided  will  be  timely  and  satisfac- 
tory; 

(e)  Includes  assurances  that  infor- 
mation in  the  computer  system  as  well 
as  access,  use.  and  disposal  of  ADP 
data  will  be  safeguarded  in  accordance 
with  provisions  of  45  CFR  205.50  and 
45  CFR  302.18;  and 

(f)  Requires  the  provider  to  obtain 
prior  approval  from  the  Department 
for  ADP  equipment  and  ADP  services 
that  is  acquired  primarily  to  support 
the  titles  covered  by  this  subpart  and 
requires  the  provider  to  comply  with 
45  CFR  Part  74,  Subpart  P  for  pro- 
curements related  to  the  service  agree- 
ment. 

"Software"  means  a  set  of  computer 
programs,  procedures,  and  associated 
documentation  by  which  ADP  equip- 
ment is  used  and  operated. 

"State  agency"  means  the  State 
agency  administering  or  supervising 
the  administration  of  the  State  plan 
that  is  required  by  the  Department  for 
the  Social  Security  Act  programs. 

"System  design"  means  the  putting 
together  of  a  new  or  more  efficient 
ADP  system. 

"System  specifications"  means  infor- 
mation about  the  new  ADP  system- 
such  as  workload  descriptions,  input 
data,  information  to  be  maintained 
and  processed,  data  processing  tech- 
niques, and  output  data— which  is  re- 
quired to  determine  the  ADP  equip- 
ment and  software  necessary  to  imple- 
ment the  system  design. 

"System  study"  means  the  examina- 
tion of  existing  information  flow  and 
operational  procedures  within  an  orga- 
nization. The  study  essentially  consists 
of  three  basic  phases:  data  gathering. 
Investigation   of   the   present  system 


and  new  information  requirements; 
analysis  of  the  data  gathered  In  the  in- 
vestigation; and  synthesis,  or  refitting 
of  the  parts  and  relationships  uncov- 
ered through  the  analysis  into  an  effi- 
cient system. 

[43  FR  44853.  Sept.  29,  1978,  a£  amended  at 
45  FR  10794,  Feb.  19.  1980] 

Specific  Conditions  for  FFP 

§  95.611     Prior  approval  conditions. 

(a)  General-Acquisition  reQuirpmenL 
A  State  shall  obtain  prior  written  ap- 
proval from  the  Department  when  it 
plans  to  acquire  ADP  equipment  or 
services  that  it  anticipates  will  have 
total  acquisition  co.sts  of  $100,000  or 
more  in  Federal  and  State  funds  over 
a  twelve-month  period,  or  $200,000  or 
more  in  Federal  or  State  funds  for  the 
total  acquisition.  A  State  shall  also 
obtain  prior  written  approval  from  the 
Department  when  it  plans  to  acquire 
noncompetitively  from  a  commercial 
source  ADP  equipment  or  services 
that  cost  more  than  $25,000  in  Federal 
and  State  funds.  The  State  shall 
submit  requests  for  prior  systems  ap- 
proval, signed  by  the  appropriate 
State  official,  to  the  Assistant  Secre- 
tary for  Management  and  Budget 
(ASMB),  Department  of  Health  and 
Human  Services.  Requests  from  States 
shall  indicate  clearly  the  Social  Secu- 
rity Act  titles  under  which  funding  is 
requested,  and  the  estimated  amount 
or  percent  that  is  requested  for  each 
title.  The  State  shall  send  three  copies 
of  the  request  for  each  component  to 
the  Department  that  must  approve 
the  request.  The  Department  will  ac- 
knowledge receipt  of  the  State  re- 
quest. 

(b)  Specific  prior  approval  require- 
ments. The  State  agency  shall  obtain 
written  approval  of  the  Department: 

(1)  For  the  advance  planning  docu- 
ment or  any  change  of  the  advance 
planning  document  prior  to  entering 
into  contractual  agreements  or  making 
any  other  commitment  for  acquisition 
of  ADP  equipment  or  ADP  services; 

(2)  For  the  service  agreement  (when 
data  processing  services  are  to  be  pro- 
vided by  a  State  central  data  process- 
ing facility  or  by  another  State  or 
local  agency); 
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(3)  For  the  request  for  proposal 
(RFP),  prior  to  its  issuance  when  serv- 
ice or  equipment  proposals  are  being 
solicited  from  commercial  sources; 

(4)  When  required,  for  the  contract, 
prior  to  signature  of  the  contracting 
officer.  The  Department  requires  ap- 
proval of  the  contract  for  complex 
procurements,  or  where  the  grantee 
has  a  history  of  performance  prob- 
lems. 

(5)  When  required  for: 
(1)  The  feasibility  study; 
(ii)  The  system  study; 
<iii)  The  system  design; 

(iv)  The  system  specifications;  and 

(V)  The  acceptance  document. 

The  Department  will  notify  the 
State  agency  if  such  prior  approval  is 
required  under  §  95.611(b)  (4)  or  (5). 

(c)  Prompt  action  on  requests  for 
prior  approval.  The  ASMB  will 
promptly  send  to  the  approving  com- 
ponents the  items  specified  in  para- 
graph (b)  of  this  section.  If  the  De- 
partment has  not  communicated  ap- 
proval or  disapproval  within  30  days 
the  ASMB  or  an  approving  component 
will  notify  the  State  regarding  the 
status  of  the  request. 

[43  FR  44853.  Sept.*  29.  1978,  as  amended  at 
45  FR  10794.  Feb.  19.  1980] 

§95.612    Prior  notice  conditions. 

(a)  General— $25,000  to  $100,000  ac- 
quisition requirements.  A  State  shall 
notify  the  Department  (ASMB)  when 
it  plans  to  acquire  ADP  equipment  or 
sen'ices  that  will  cost  S25,000  to 
$100,000  over  a  twelve-month  period  in 
Federal  and  State  funds.  The  State 
shall  send  the  prior  notice  of  acquisi- 
tion to  the  Department  60  days  before 
the  planned  acquisition. 

(b)  Specific  prior  notice  contents. 
The  prior  notice  of  acquisition  is 
signed  by  the  appropriate  State  offi- 
cial and  explains: 

(1)  The  need  the  acquisition  is  in- 
tended to  satisfy: 

(2)  The  nature  and  scope  of  tin.'  ac- 
quisition: 

(3)  Alternatives  to  the  acquisition: 

(4)  If  acquired  from  commercial 
sources,  assurance  that  the  State  or 
local  government  will  competitively 
acquire  the  ADP  equipment  or  service: 

(5)  Total  cost  of  the  acquisition: 
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(6)  The  Social  Security  Act  titles  th,„«r 
State  intends  to  charge  for  the  acqui- 
sition  and  the   estimated  amount  or 
percentages  the  State  plans  to  charge 
to  each  title;  and 

(7)  Any  additional  information  the 
Department  requires. 

[45  FR  10794.  Feb.  19.  1980] 
§95.613    Procurement  standards. 

Procurements  of  ADP  equipment 
and  services  are  subject  to  the  pro- 
curement standards  in  subpart  P,  45 
CFR,  part  74.  Those  standards  mclude 
a  requirement  for  maximum  practical 
open  and  free  competition  regardless 
of  whether  the  procurement  is  formal- 
ly advertised  or  negotiated.  Those 
standards,  as  well  as  the  requirement 
for  prior  approval,  apply  to  ADP  serv- 
ices and  equipment  acquired  by  a 
State  or  local  agency,  and  to  ADP 
services  and  equipment  acquired  by  a 
State  or  local  central  data  processing 
facility  primarily  to  support  the  Social 
Security  Act  programs  covered  by  this 
subpart.  The  service  agreement  be- 
tween the  State  agency  and  the  State 
central  data  processmg  facility  is 
exempt  from  the  procurement  stand- 
ards because  State  and  local  govern- 
ment agencies  are  not  required  to  com- 
pete with  the  private  sector.  ^^^ 

(43  FR  44853.  Sept.  29.  1978;  43  FR  53039.'^^ 
Nov.  15.  1978.  as  amended  at  45  FR  10794. 
Feb.  19,  1980] 

§  95.615     Access  to  records. 

In  accordance  with  45  CFR  Part  74. 
the  State  agency  must  allow  the  De- 
partment access  to  the  system  in  all  of 
its  aspects,  including  design  develop- 
ments, operation,  and  cost  records  of 
contractors  and  subcontractors  at  such 
intervals  as  are  deemed  necessary  by 
the  Department  to  determine  w^hether 
the  conditions  for  approval  are  being 
met  and  to  determine  the  efficiency, 
economy  and  effectiveness  of  the 
system. 

[43  FR  44853.  Sept.  29.  1978,  as  amended  at 
45  FR  10794,  Feb.  19,  1980] 

§95.617    Software  and  ownership  rights. 

(a)  General.  The  State  or  local  gov- 
ernment will  have  all  ownership  rights 
in  software  or  modifications  thereof 
and  associated  documentation  de- 
signed,   developed    or    installed    with 
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§  95.633 


Federal  financial  participation  under 
this  subpart. 

(b)  Exemption.  The  Department  re- 
serves a  royalty-free,  nonexclusive, 
and  irrevocable  license  to  reproduce, 
publish,  or  otherwise  use  and  to  au- 
thorize others  to  use  for  Federal  Gov- 
ernment purposes,  such  software, 
modifications,  and  documentation. 

(c)  Proprietary  software.  Proprietary 
software  which  is  provided  at  estab- 
lished catalog  or  market  prices  and 
sold  or  leased  to  the  general  public 
shall  not  be  subject  to  the  ownership 
provisions  of  this  subpart. 

C43  FR  44853.  Sept.  29.  1978,  as  amended  at 
45  FR  10794.  Feb.  19.  1980] 

S  95.619     Use  of  ADP  systems. 

ADP  systems  designed,  developed,  or 
installed  with  Federal  financial  par- 
ticipation shall  be  used  for  a  period  of 
time  specified  in  the  advance  planning 
document,  unless  the  Department  de- 
termines that  the  elapsed  shorter 
period  of  time  is  sufficient  to  justify 
the  Federal  funds  invested. 

[43  FR  44853.  Sept.  29.  1978,  as  amended  at 
45  FR  10794,  Feb.  19.  19801 

B  95.621     ADP  reviews. 

The  Department  will  conduct  peri- 
odic onsite  surveys  and  reviews  of 
State  and  local  agency  ADP  methods 
and  practices  to  determine  the  adequa- 
cy of  such  methods  and  practices  and 
to  assure  that  ADP  equipment  and 
services  are  utilized  for  the  purposes 
consistent  with  proper  and  efficient 
administration  under  the  Act.  Where 
practical,  the  Department  will  develop 
a  mutually  acceptable  schedule  be- 
tween the  Department  and  Slate  or 
local  agencies  prior  to  conducting  such 
surveys  or  reviews,  which  may  Include 
but  are  not  limited  to; 

(a)  Pre-installalion  readiness.  A  pre- 
installation  survey  including  an  onsite 
evaluation  of  the  physical  site  and  the 
agency's  readiness  to  productively  use 
the  proposed  ADP  services,  equipment 
cr  system  when  Installed  and  oper- 
ational. 

(b)  Post-installation.  A  review  con- 
ducted after  installation  of  ADP 
equipment  or  systems  to  assure  that 
the  objectives  for  which  FTT"  was  ap- 
proved are  being  accomplished. 


(c)  Utilization.  A  continuing  review 
of  ADP  facilities  to  determine  whether 
or  not  the  ADP  equipment  or  ser%'iccs 
are  being  efficiently  utilized  in  sup- 
port of  approved  programs  or  projects. 

§  95.623    Waiver  of  prior  approval  require- 
ments. 

ADP  equipment  and  services  ac- 
quired by  a  State  agency  prior  to  the 
effective  date  of  these  regulations  may 
qualify  for  FFP  provided  the  Depart- 
ment waives  the  prior  approval  re- 
quirement. The  Department  will  waive 
the  prior  approval  requirement  when 
it  determines  that  the  ADP  equipment 
or  services  would  have  received  prior 
approval  had  a  request  for  such  ap- 
proval been  made  by  the  State  agency. 

Cost  Allocation  Plan 

§95.631     Relationship  to  the  approved  cost 
allocation  plan. 

(a)  General  The  conditions  of  this 
subpart  apply  notwithstanding  the  ex- 
istence of  an  approved  cost  allocation 
plan.  States  that  operate  with  a  cen- 
tral data  processing  facility  shall  use 
the  approved  cost  allocation  plan  bill- 
ing rates  and  billing  methods  in  the 
service  agreement  with  the  State 
agency.  The  State  shall  bill  the  De- 
partment, at  the  approved  rates,  for 
the  ADP  equipment  and  services  used 
by  the  Individual  Department  pro- 
grams. 

cb)  Impact  on  the  cost  allocation 
plan.  ADP  equipment  and  services 
purchased  or  leased  by  the  State  cen- 
tral data  processing  facility  may  cause 
a  change  to  the  approved  cost  alloca- 
tion plan.  (For  example,  the  lease  of 
an  additional  nondedicated  computer.) 
When  a  change  Is  necessary,  the  State 
shall  revise  the  billing  rates  and  bill- 
ing methods  prior  to  revising  the  serv- 
ice agreement. 

§95.633     Nondiscrimination  requirements. 

State  agencies  that  acquire  ADP 
equipment  and  services  are  subjf^ct  to 
the  nondiscrimination  requirements  In 
ParU  80.  84.  and  90. 

[45  FR  10794,  Feb.  19.  1980) 
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Title  45— Public  Welfare 


Exemptions 


§95.G41  Exemption  from  45  C='R 
205.160<a)  and  304.24. 
The  capitalization  and  depreciation 
provisions  of  45  CFR  205.160(a)  and 
304.24  do  not  apply  to  ADP  equipment 
provided  the  purchase  benefits  the  De- 
partment and  provided  the  Depart- 
ment agrees  to  the  ADP  equipment 
purchase. 

§95.64.3  Exemption  from  45  CFK  Part  71, 
Appendix  C,  Part  11,  C.l. 
The  requirement  in  45  CFR  Part  74, 
Appendix  C,  Part  II.  C.l.  for  prior  ap- 
proval of  ADP  equipment  and  services 
is  waived  for  items  that  cost  $25,000  or 
less. 

PART  99— PRIVACY  RIGHTS  OF 
PARENTS  AND  STUDENTS 


Subport  A — General 


Sec. 
99.1 
99.2 
993 
99.4 
99.5 


Applicability  of  part. 
Purpose. 
Definitions. 
Student  rights. 

Formulalion    of    institutional 
and  procedures.' 

99.6  Annual  notification  of  rights. 

99.7  Limitation  on  waivers. 

99.8  Fees. 


policy 


Subpart  B — Inspection  ond  Review  of 
Education  Recordi 

99.11  Right  to  inspect  and  review  educa- 
tion records. 

99.12  Limitations  on  right  to  inspect  and 
review  education  records  at  the  poslsoc- 
ondary  level. 

99.13  Limitation  on  destruction  of  educa- 
tion records. 

Subpart  C — Amendment  of  Education  Records 

99.20  Request  to  amend  education  records. 

99.21  Right  to  a  hearing. 

99.22  Conduct  of  the  hearing. 

Subpart  D — Oitcloture  of  Personally 

Identifiable  Informotion  From  Educotlon 

Records 

99.30  Prior  consent  for  disclosure  required. 

99.31  Prior  consent  for  disclosure  not  re- 
quired. 

99.32  Record  of  requests  and  disclosures 
required  to  be  maintained. 

99.33  Limitation  on  redisclosure. 


Sec.  ""^ 

99.34  Conditions  for  disclosure  to  officials 
of  other  schools  or  school  systems. 

99.35  Disclosure  to  certain  Federal  and 
State  officials  for  Federal  program  pur- 
poses. 

99.36  Conditions  for  disclosure  in  health 
and  safety  emergencies. 

99.37  Conditions  for  disclosure  of  directory 
information. 

Subpart  E — Enforcement 

99.60  Office  and  review  board. 

99.61  Conflict  with  Stale  or  local  law. 

99.62  Reports  and  records. 

99.63  Complaint  procedure. 

99.64  Termination  of  funding. 

99.65  Hearing  procedures. 

99.68    Hearing  before  Panel  or  a  Hearing 

Officer. 
99.67    Initial  decision;  final  decision. 

Authority:  Sec.  438.  Pub.  L.  90-247.  Title 
IV,  as  amended.  88  Stat.  571-574  (20  U.S.C. 
1232g). 

Source:  41  FR  24670,  June  17,  1976.  unless 
otherwise  noted. 

Subpart  A — General 

§  99.1     Applicability  of  part. 

(a)  This  part  applies  to  all  educa- 
tional agencies  or  institutions  to  which 
funds  are  made  available  under  any 
Federal  [program  for  which  the  U.S.^^ 
Commissioner   of    Education    has    ad-^^ 
ministrative  responsibility,  as  specified 

by  law  or  by  delegation  of  authority 
pursuant  to  law.] 

(20  U.S.C.  1230.  1232g) 

(b)  This  part  does  not  apply  to  an 
educational  agency  or  institution 
solely  because  students  attending  that 
non-monetary  agency  or  institution  re- 
ceive benefits  under  one  or  more  of 
the  Federal  programs  referenced  in 
paragraph  (a)  of  this  section,  if  no 
funds  under  those  programs  are  made 
available  to  the  agency  or  institution 
itself. 

(c)  For  the  purposes  of  this  part, 
funds  will  be  considered  to  have  been 
made  available  to  an  agency  or  institu- 
tion when  funds  under  one  or  more  of 
the  programs  referenced  in  paragraph 
(a)  of  this  section:  (1)  Are  provided  to 
the  agency  or  institution  by  grant, 
contract,  subgrant,  or  subcontract,  or 
(2)  are  provided  to  students  attending 
the    agency    or    institution    and    the 
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APPENDIX  "E" 


MONTANA  DEPARTMENT  OF  SOCIAL  AND  REHABILITATION  SERVICES 
POLICIES  AND  PROCEDURES  ON  CLIENT  CONFIDENTIALITY 


DEFINITIONS 


REASONS  FOR 
THESE  RULES 


Client  Record:  a  system  of  information  regarding  an  indivi- 
dual client  and  his  or  her  family  which  is  formally  maintained. 
Includes  any  conputer  or  other  magnetic  records  and  manual 
case  file  records  maintained  by  the  Montana  Department  of 
Social  and  Rehabilitation  Services  and  its  subdivisions » 
Department  of  Social  and  Rehabilitation  Services:  for  pur- 
poses of  client  confidentiality,  the  Department  of  Social 
and  Rehabilitation  Services  includes: 

1.  Employees  of  the  Department  including  all  county,  district, 
regional  and  state  personnel; 

2.  Employees  or  menbers  of  official  boards,  councils  or 
teams  established  for  purposes  of  performing  duties  connected 
with  the  administration  of  SRS  programs;  and 

3.  Persons  who  contract  with  the  Department  or  are  canployed 
by  organizations  which  contract  with  the  Department 

SRS:  Abbreviation  for  the  Montana  Department  of  Social  and 
Rehabilitation  Services. 

M2A:  Abbreviation  for  a  10- volume  set  of  books  called,  the 
^iontana  Codes  Annotated  which  contain  current  Montana  laws. 

These  policies  and  procedures  are  established  to  provide 
general  guidance  regarding  safeguarding  of  client  information. 
They  are  not  meant  to  be  all  encorripassing .  Individual 
program  units  within  the  Department  may  establish  more 
stringent  criteria.  Therefore,  consult  applicable  program 
manuals  for  further  information  on  this  subject. 
If  you  are  uncertain  about  a  particular  circumstance  in 
which  you  are  involved,  contact  the  Legal  Services  Unit, 
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APPLICATION 
INTORMATION 


CLIEOT 


Director's  Office,  Department  of  SRS. 

Information  required  on  application  fonns:  all  SRS  application 
forms  must  state  tliat  the  information  provided  by  the  applicant 
is  confidential  aiid  vail  be  used  for  purposes  directly  related 
to  the  administration  of  the  program  or  related  programs. 
If  social  security  numbers  are  requested; 

1.  Whether  disclosure  of  social  security  numbers  is  required 
or  voluntary; 

2.  If  social  security  numbers  are  required,  the  statute  that 
gives  authority  for  requiring  disclosure; 

3.  Specific  descriptions  of  the  uses  to  be  made  of  the  social 
security  numbers;  and 

4.  The  effect,  if  any,  of  not  providing  all  or  part  of  the 
requested  information. 

Possession  of  SRS  Client  Records:  the  client  records  of  the 


Department  of  Social  aixi  Rehabilitation  Services  are  the 
property  of  the  Department  and  are  to  be  protected.  These 
records  must  not  leave  the  possession  of  the  Department  or 
its  enployees.  Records  must  not  be  removed  from  the 
property  of  the  Department  unless  necessary.  If  it  is 
necessary  to  mail  records,  they  should  be  sent  under 
certified  mail. 

Maintaining  client  records:  all  client  records  are  poten- 
tially open  to  review  by  the  client  or  other  persons.  There- 
fore, client  records  should  be  maintained  in  an  orderly, 
formal  manner  using  objective  facts  as  to  circumstances  and 
activities  in  the  case  as  much  as  possible.  Information 


concerning  the  Department's  evaluations  of  these  facts 

will  have  to  be  present.  Tliese  evaluations  should  be  set 

apart  and  stated  as  objectively  as  possible. 

C0^3FIDENTIAL 

INRDRMATION     Penalty  for  Misuse;  it  is  unlawful  to  disclose  or  use  lists 

or  names  of  public  welfare  recipients  for  any  purposes  not 
directly  connected  with  the  administration  of  public  assis- 
tance or  for  coTOiercial  or  political  purposes  of  any  nature. 
The  penalty  upon  conviction  shall  be  a  fine  of  not  less  than 
$25  or  more  than  $1000  to  \^Mch  may  be  added  inprisonment  in 
the  county  jail  for  any  determinate  period  not  to  exceed  60 
days.   (MHA  53-2-105  and  53-2-106)   Administrative  purposes 
include  determining  eligibility,  determining  amounts  of 
assistance,  and  providing  services  for  applicants  and 
recipients. 

Considerations :  there  are  tvro  factors  to  consider  when 
making  a  determination  as  to  whether  to  release  information 
about  a  particular  applicant  or  recipient.  These  are: 

1.  The  public's  right  to  know;  and 

2.  The  individual's  right  to  privacy. 

These  two  subjects  are  addressed  in  Montana's  Consitution, 
Article  II,  Sections  9  and  10.  The  public  has  a  right  to 
observe  and  examine  how  public  agencies  operate.  Applicants 
and  recipients  have  a  right  to  know  what  our  rules  are  and 
why  we've  made  certain  evaluations  of  their  circumstances. 
However,  applicants  and  recipients  also  have  a  right  to 
privacy,  and  there  must  be  a  conpelling  state  interest  sho^vn 
before  any  type  of  information  is  released  that  might 
anbarrass  or  damage  the  reputation  of  the  individual  or 
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family  involved. 

Confidential  information  includes: 

1.  Names,  addresses  ard  social  security  numbers  of 
applicants  aj:d  recipients  of  public  assistance; 

2.  Information  related  to  the  social  and  econorac  conditions 
or  circumstances  of  a  particular  individual; 

3.  Department  evaluations  of  information  about  a  particular 
individual ;  and 

4.  Medical  data,  including  diagnosis  and  past  history  of 
disease  or  disability  concerning  a  particular  individual. 

Confidentiality  for  3rd  parties:  individuals  vto  report 
possible  program  abuses  by  applicants  or  recipients  are 
guaranteed  anonymity.  This  is  also  true  upon  request 
for  individuals  who  refer  persons  or  families  for 
protective  service  investigations.  Under  no  circumstances 
will  the  names  or  identifying  information  concerning  such 
individuals  be  released.  Remove  all  such  references  prior 
to  any  release  of  client  records. 

Routine  Releases  of  Information:  routine  releases  of  infor- 
mation can  be  made  without  authorization  of  the  applicant  or 
recipient  involved  and  without  special  notation  in  the 
client  record.  This  includes  (1)  information  released  which  is 
not  and  cannot  be  identified  with  a  particular  applicant  or 
recipient  and  (2)  confidential  information  released  for  purposes j 
directly  related  to  the  administration  of  SRS  programs  or 
directly  related  to  the  administration  of  programs  with 
compatible  purposes.  Routine  releases  of  confidential 
information  can  be  made  ujxier  the  following  circumstances: 
1.  When  the  release  is  within  the  Department  of  SRS; 


2.  When  the  release  is  to  federal  and  state  auditors  ^^rorking 
in  their  official  capacities; 

3.  Uhen  the  release  is  to  the  ^tontana  Department  of  Revenue 
for  purposes  of  investigating  the  airounts  of  public  assistance 
{^K:A  53-2-501  through  504)  ; 

4.  ;%hen  the  release  is  to  Child  Protective  Team  menibers 
operating  in  their  official  capacities  (MCA  41-3-108  and 

205(2); 

5.  \-hen  other  existing  laws  require  the  release  of 
information  in  specific  instances;  and 

6.  V.hen  the  release  is  to  an  organization  whose  programs 
supplement  the  programs  of  the  Department,  e.g.  to  Public 
Health  Departments  to  further  provision  of  the  Early  Periodic 
Screening  Diagnosis  and  Treatment  Program. 

^Jow-RcuT^we     j^fon-Poutine  Releases  of  Information:  any  request  for  release 
of  client  records  that  is  not  defined  as  a  routine  release 
requires  that  the  following  policies  and  procedures  are 
follo\';ed.  ,  Two  general  areas  are  covered:   (1)   access  to  a 
person's  own  client  records,  and  (2)  access  to  client  records 
by  persons  other  thaii  the  applicant/recipient. 

Rec^AS^S  TX.        ^^^^^^  ^^  a  person's  own  client  record  (includes  releases 

THE  flpPt)C/}Wi/    • ■ ^ 

^£C.P.£.0T      ^^  ^^^^  children  and  releases  to  legal  guardians  of  adults)  : 

f^.^he   applicant  or  recipient  must  supply  the  following 
information.  It  must  be-put  in  writing,  sigr-ed  by  the 
applicant  or  recipient  and  filed  in  the  client  record. 

(1)  Name  and  address; 

(2)  Types  of  information  to  be  reviewed,  i.e.  case 
record  concerning  my  eligibility  for  AFDC  in  1978; 

-— '    (3)  Date  of  the  request;  and 
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the  review  should  be  done  in  the  SRS  office  and  an  SRS 
representative  must  be  present  during  the  review; 

(3)  -me  informtion  reviews!  must  include  only  infoma- 
tibn  concerrAng  the  rojuestor  and/or  minor  children  in 
his  or  her  legal  custody;  and 

(4)  Certain  medical  records   (as  described  below  under 
"Special  Circumstances") may  have  to  b3  withheld  from 

review. 

upon  request,  information  from  the  client  record  can  be  dupli- 
cated by  an  SRS  representative  and  a  reasonable  fee  assessed 

to  the  requesting  party. 

(Z)   The  follCTving  information  regarding  the  review  n 
in  writing  and  filed  in  the  client  record: 

(1)  The  date  and  time  of  the  review; 

(2)  The  type (s)  of  information  that  was  reviewed; 

(3)  The  type{s)  of  information  that  was  duplicated; 

(4)  l^e  name  and  address  of  the  party  to  whom  infoi 
tion  was  released;  and 

(5)  The  signature  and  title  of  the  SPS  representat 
who  supervised  the  review. 

Special  circumstances; 

(1)  Client  records  containing  information  on  more 

one  family  manber: 

(a)  Adults  (including  spouses)  requesting  re 
client  records  concerning  other  adults  in  th  ■ 
family  should  follow  procedures  outlined  for 
to  client  records  by  other  than  the  applicar 
recipient"  unless  a  legal  guardianship  has  i 
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established; 


(b)  Except  for  certain  medical  records,  parents  of   aaardJcvpS 

may  review  all  records  concerning  children  in  their 

0  iV^ 

legal  custody^  rdM.v,(2)  ^,^  cAu^jAdAA^  ^^7!/)til  .*<ukjuo^O^  hm^ 

-  If  the  child  is  urder  the  legal  custody  of  SFS, 
a  responsible  SRS  representative  must  make  the 
determination  as  to  whether  to  allow  the  parents  to 
review  the  child's  records. 

-  If  parents  are  divorced,  the  parent  having  legal 
custody  must  give  authorization  for  the  other  parent  to 
have  access.      , 

(2)  Medical« records  including  any  reports  from  physicians, 
psychiatrists,  ps]>'cho legists ,  child  development 
specialists  or  other  health  professionals  may  require 
special  treatment =  If  there  are  doi±)ts  about  the  extent 
of  an  applicant/recipient's  knowledge  of  such  records 
and  the  information  is  potentially  damaging,  the 
following  steps  should  be  followed: 

(a)  Inform  the  individual  that  certain  medical 
records  have  been  removed  from  the  record; 

(b)  Ask  the  individual  to  sign  a  release  of 
information  form  directed  to  a  health  professional  ^7^  ^i^'^u-^^^^' 
(not  a  relative) of  their  choosing;  and 

(c)  Tell  the  individual  that  they  can  make  an 
appointment  with  the  health  professional  to  discuss 
the  records. 

oi>\e.ft  PfcESci^S  2*  _^ccess  to  client  records  by  persons  other  than  the 
applicant/recipient : 

a.  The  request  must  be  in  writing,  filed  in  the 
client  record  and  include: 


'^^ta.'f^ 
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(1)  the  name  of  the  person  requesting 
the  information; 

(2)  the  organization  (if  any)  with  whie 
the  person  is  associated; 

(3)  the  person's  (or  organization's) 
address; 

(4)  the  name(s)  of  the  person(s) 
concerningyi information  is 
being  requested; 

(5)  types  of  information  to  be 
reviewed; 

\S)    the  manner  in  which  the  infor- 
mation will  be  used;  and 
(7)  the  date  of  the  request  and  the 
signature  of  the  requestor, 
b.   Applicant/recipient  approval  for  the  release: 

(1)  Provide  the  applicant/recipient  with  the 
information  that  the  requestor  supplied  in 
section  2a;  and 

(2)  Whenever  possible,  have  the  applicant/ 
recipient  sign  a  Release  of  Information  form 

(SRS-AD- )  directed  to  the  requestor  and  file 

in  the  client  record.  If  the  applicant/recipient 
prefers  giving  verbal  authorization,  document 
that  the  information~supplied  by  the  requestor  in 
section  2a  was  provided  to  the  individual  and  the 
date  on  which  approval  was  given.  The  SRS 
representative  should  then  sign,  date  and  provide 
their  title  on  this  documentation  and  file  in  the 


■"■'''"••^-•"■^"''*— » 
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client  record. 

(c)  The  following  information  regarding  the  review 
must  be  put  in  writing  and  filed  in  the  client  record: 

(1)  The  date  and  time  information  was  reviewed; 

(2)  The  type(s)  of  information  that  was  reviewed; 

(3)  The  type(s)  of  information  that  was  duplicated 

(4)  The  name  and  address  of  the  party  to  whom 
information  was  released;  and 

(5)  The  signature  and  title  of  the  SRS • 
representative  who  supervised  the  release. 

The  SRS  representative  should  make  clear  to  any 
outside  party  who  is  granted  access  to  a  client 
record  that  the  release  was  authorized  only  for 
the  purposes  that  the  requestor  specified  (see 
section  2a (6)  above.   This  must  be  done  either 
verbally  or  in  writing. 


(OtteM  TO         ^^ho  can  review  client  records: 


1.  If  the  applicant  or  recipient  approves  a  release 
to  a  specific  party  or  organization:   the  record  can 
be  reviewed  or  released  as  if  the  applicant/recipient 
were  accessing  the  record  her  or  himself.   If  infor- 
mation concerning  other  family  members  is  present, 

a  release  for  each  individual  as  specified  above 

must  be  authorized  or  the  information 

must  be  removed  from  the  record  prior  to  review. 

2.  If  the  applicant/recipient  has  not  given  prior 
approval  for  the  release:   this  may  occur  when  there 
is  an  immediate  need  for  the  information  such  as 

iw"—  y       when  medical  treatment  or  criminal  proceedings  are 

'      •.  -  ^.. »»-- —  — T-k«  ^. —  ^..l^^-a.  /^.l■...  •.,  i^    ~^  r — .-  -  II.- 


applicant.   All  releases  without  prior  authorization 
should  be  avoided. 

-  Court  Subpoenas  -  if  a  court  subpoenas  a  client  recc 
and  the  recipient/applicant  either  has  i ot  approved  tl 
release  or  objects  to  the  release,  a  letter  should  be 
written  to  the  court  stating  the  following: 

a.  The  records  of  the  Department  of  SRS  are 
confidential  by  authority  of  MCA  53-2-105  and 

53-2-106; 

b.  (Either)  this  Department  has  been  unable  to 
reach  (the  applicant's  name)  to  authorize  the 
release  of  this  information  (or) 

(the  applicant's  name)  objects  to  the 
release  of  this  information; 

c.  A  representative  of  the  Department, 
(representative's  name),  will  deliver  the  recorc 
to  the  court  on  the  date  specified  by  the 
subpoena  and  will  ask  permission  to  be 
present  during  all  reviews  or  duplication  of  th 
records.   However,  we  ask  that  the  court  consid 
the  confidentiality  laws  which  apply  to  the 
Department  of  SRS  in  requesting  this  release. 

3.   Access  to  client  records  when  the  applicant/ 
recipient  is  deceased:   normally  access  to  client 
records  concerning  deceased  persons  is  granted  unles 
there  is  good  cause  to  anticipate  damage  to  a  livinc 
relative  as  a  result. 
?c^a^el^£COftt>S   A-      Access  to  computer  records:   if  releases  of 

computer  records  are  requested,  send  a  copy  of  the 
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REQUESTS  FOR 
CORRECTIONS 


rc.a,aes^ecl  j.e- ArbC  veCcv-ds,  ^'^•cA■lca^c\  reec^^d,  Social  ■S^*'Oi( 
rc^^cis   ^Vic\x\ci   be  sp«<ii^;£cl.  T'he  \reCcocis  >i\a.\^  be  Seaf 

re  fi*"c^«^farWc-      fcY-      vcveto,  .  ,         •     .       ^ 

and   clarification  with   the   applicant/recipient   prioi 

to  release. 

^.   Releases  for  purposes  of  Research  Projects;   if 
there  are  requests  for  client  confidential 
information  for  research  purposes  by  individuals  noi 
employed  by  SRS,  an  evaluation  of  the  circumstances 
will  be  required.   Contact  an  SRS  state 
office  program  person,  who  will  in  turn  talk  with 
SRS  Legal  staff  for  a  determination. 

Applicants/recipients  who  disagree  with  the  infor- 
mation contained  in  their  client  records,  have  a 
right  to  request  that  the  records  be  corrected. 
The  following  proceedures  should  be  followed: 
1.   The  applicant/recipient  or  his  or  her 
representative  must  put  the  request  in  writing 
and  include: 

a.  The  date; 

b.  The  specific  information  which  is  being 
contested; 

c.  A  statement  as  to  how  they  want  the  record 
to  be  corrected  (i.e.  the  information  should 
be  corrected  to  state  ".  .  .  "or  the  infor- 
mation should  be  removed  from  the  record) . 

d.  Their  signature (s) . 

2.  The  SRS  representative  who  receives  this  reques 
must  make  one  copy  of  the  request,  file  the  origins 
in  the  client  record,  send  the  copy  of  the  request 
and  copies  of  the  client  record  information  which  ; 


supervising  unit  for  review  with  SRS  legal  staff; 

3.  An  initial  determination  as  to  whether  the  client 
record  will  be  modified  must  be  made  within  30  days. 
Within  7  days  of  receipt  of  the  request,  the  SRS 
representative  who  received  the  request  must  notify 
the  applicant/recipient  in  writing  that  an 

initial  determination  wiJ.l  be  forwarded  to  them  withi 
30  days  and  file  this  correspondence  in  the  client 
record; 

4.  Every  effort  should  be  made  to  resolve  the 
disagreement  in  a  manner  acceptable  to  both  parties 
at  this  stage.   Once  a  final  determination  is  made, 
the  applicant/recipient  must  be  notified  in 
writing  of  the  actions  that  will  be  taken  to  correct 
the  client  record.   This  correspondence  must  be 
filed  in  client  record  and  include: 

a.   Notification  that  if  they  are  still  dis- 
satisfied, they  may  request  a  fair  hearing  by 
writing  to: 

Hearings  Officer 

Office  of  Administration 

Department  of  SRS 

Box  4  210 

Helena,  Montana   59604 

b.-   Notification  that  all  other  SRS  records 

containing  this  information  are  being  modified; 

c.   Notification -that  the  agency  is  making  every 

effort  to  notify  all  other  agencies  and  parties 

who  had  prior  access  to  the  information  that 

was  modified,  that  the  information 

was  in  error  and  how  it  was  corrected. 


5.   Every  effort  will  be  made  to  contact  all  parties 
or  organizations  who  had  prior  access  to  the  infor- 
mation which  was  corrected  that  the  information 
was  in  error  and  how  it  was  corrected. 
6.   If  SRS  does  not  correct  the  information  being 
contested  and  the  applicant/recipient  continues  to 
contest  the  information,  a  short  statement  concerni, 
the  applicant's/recipient's  disagreement  with  the 
information  must  be  filed  in  all  records  (including 
computer  records)  containing  that  information.   Any 
time  the  information  is  released,  the  applicant's/ 
recipient's  statement  must  accompany  the  release. 
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